%% license is included in the section entitled "GNU Free Documentation
%% License".
%%
-
\chapter{La gestione avanzata dei file}
\label{cha:file_advanced}
+
In questo capitolo affronteremo le tematiche relative alla gestione avanzata
dei file. Inizieremo con la trattazione delle problematiche del \textit{file
locking} e poi prenderemo in esame le varie funzionalità avanzate che
contemporaneamente sullo stesso file non è possibile determinare la sequenza
in cui essi opereranno.
-Questo causa la possibilità di una \itindex{race~condition} \textit{race
- condition}; in generale le situazioni più comuni sono due: l'interazione fra
-un processo che scrive e altri che leggono, in cui questi ultimi possono
-leggere informazioni scritte solo in maniera parziale o incompleta; o quella
-in cui diversi processi scrivono, mescolando in maniera imprevedibile il loro
-output sul file.
+Questo causa la possibilità di una \textit{race condition}; in generale le
+situazioni più comuni sono due: l'interazione fra un processo che scrive e
+altri che leggono, in cui questi ultimi possono leggere informazioni scritte
+solo in maniera parziale o incompleta; o quella in cui diversi processi
+scrivono, mescolando in maniera imprevedibile il loro output sul file.
In tutti questi casi il \textit{file locking} è la tecnica che permette di
-evitare le \itindex{race~condition} \textit{race condition}, attraverso una
-serie di funzioni che permettono di bloccare l'accesso al file da parte di
-altri processi, così da evitare le sovrapposizioni, e garantire la atomicità
-delle operazioni di lettura o scrittura.
+evitare le \textit{race condition}, attraverso una serie di funzioni che
+permettono di bloccare l'accesso al file da parte di altri processi, così da
+evitare le sovrapposizioni, e garantire la atomicità delle operazioni di
+lettura o scrittura.
\subsection{L'\textit{advisory locking}}
fondamentale da capire è che un \textit{file lock}, qualunque sia
l'interfaccia che si usa, anche se richiesto attraverso un file descriptor,
agisce sempre su di un file; perciò le informazioni relative agli eventuali
-\textit{file lock} sono mantenute dal kernel a livello di \itindex{inode}
-\textit{inode}, dato che questo è l'unico riferimento in comune che possono
-avere due processi diversi che aprono lo stesso file.
+\textit{file lock} sono mantenute dal kernel a livello di \textit{inode}, dato
+che questo è l'unico riferimento in comune che possono avere due processi
+diversi che aprono lo stesso file.
In particolare, come accennato in fig.~\ref{fig:file_flock_struct}, i
-\textit{file lock} sono mantenuti in una \itindex{linked~list} \textit{linked
- list} di strutture \kstruct{file\_lock}. La lista è referenziata
-dall'indirizzo di partenza mantenuto dal campo \var{i\_flock} della struttura
-\kstruct{inode} (per le definizioni esatte si faccia riferimento al file
-\file{include/linux/fs.h} nei sorgenti del kernel). Un bit del campo
-\var{fl\_flags} di specifica se si tratta di un lock in semantica BSD
-(\const{FL\_FLOCK}) o POSIX (\const{FL\_POSIX}) o un \textit{file lease}
-(\const{FL\_LEASE}, vedi sez.~\ref{sec:file_asyncronous_lease}).
+\textit{file lock} sono mantenuti in una \textit{linked list} di strutture
+\kstruct{file\_lock}. La lista è referenziata dall'indirizzo di partenza
+mantenuto dal campo \var{i\_flock} della struttura \kstruct{inode} (per le
+definizioni esatte si faccia riferimento al file \file{include/linux/fs.h} nei
+sorgenti del kernel). Un bit del campo \var{fl\_flags} di specifica se si
+tratta di un lock in semantica BSD (\const{FL\_FLOCK}) o POSIX
+(\const{FL\_POSIX}) o un \textit{file lease} (\const{FL\_LEASE}, vedi
+sez.~\ref{sec:file_asyncronous_lease}).
\begin{figure}[!htb]
\centering
ulteriori istanze di un \textit{file lock} quanto piuttosto degli ulteriori
riferimenti allo stesso. Questo viene realizzato dal kernel secondo lo schema
di fig.~\ref{fig:file_flock_struct}, associando ad ogni nuovo \textit{file
- lock} un puntatore alla voce nella \itindex{file~table} \textit{file table}
-da cui si è richiesto il blocco, che così ne identifica il titolare. Il
-puntatore è mantenuto nel campo \var{fl\_file} di \kstruct{file\_lock}, e
-viene utilizzato solo per i \textit{file lock} creati con la semantica BSD.
+ lock} un puntatore alla voce nella \textit{file table} da cui si è richiesto
+il blocco, che così ne identifica il titolare. Il puntatore è mantenuto nel
+campo \var{fl\_file} di \kstruct{file\_lock}, e viene utilizzato solo per i
+\textit{file lock} creati con la semantica BSD.
Questa struttura prevede che, quando si richiede la rimozione di un
\textit{file lock}, il kernel acconsenta solo se la richiesta proviene da un
-file descriptor che fa riferimento ad una voce nella \itindex{file~table}
-\textit{file table} corrispondente a quella registrata nel blocco. Allora se
-ricordiamo quanto visto in sez.~\ref{sec:file_dup} e
-sez.~\ref{sec:file_shared_access}, e cioè che i file descriptor duplicati e
-quelli ereditati in un processo figlio puntano sempre alla stessa voce nella
-\itindex{file~table} \textit{file table}, si può capire immediatamente quali
-sono le conseguenze nei confronti delle funzioni \func{dup} e \func{fork}.
+file descriptor che fa riferimento ad una voce nella \textit{file table}
+corrispondente a quella registrata nel blocco. Allora se ricordiamo quanto
+visto in sez.~\ref{sec:file_dup} e sez.~\ref{sec:file_shared_access}, e cioè
+che i file descriptor duplicati e quelli ereditati in un processo figlio
+puntano sempre alla stessa voce nella \textit{file table}, si può capire
+immediatamente quali sono le conseguenze nei confronti delle funzioni
+\func{dup} e \func{fork}.
Sarà così possibile rimuovere un \textit{file lock} attraverso uno qualunque
-dei file descriptor che fanno riferimento alla stessa voce nella
-\itindex{file~table} \textit{file table}, anche se questo è diverso da quello
-con cui lo si è creato,\footnote{attenzione, questo non vale se il file
- descriptor fa riferimento allo stesso file, ma attraverso una voce diversa
- della \itindex{file~table} \textit{file table}, come accade tutte le volte
- che si apre più volte lo stesso file.} o se si esegue la rimozione in un
-processo figlio. Inoltre una volta tolto un \textit{file lock} su un file, la
-rimozione avrà effetto su tutti i file descriptor che condividono la stessa
-voce nella \itindex{file~table} \textit{file table}, e quindi, nel caso di
-file descriptor ereditati attraverso una \func{fork}, anche per processi
-diversi.
+dei file descriptor che fanno riferimento alla stessa voce nella \textit{file
+ table}, anche se questo è diverso da quello con cui lo si è
+creato,\footnote{attenzione, questo non vale se il file descriptor fa
+ riferimento allo stesso file, ma attraverso una voce diversa della
+ \textit{file table}, come accade tutte le volte che si apre più volte lo
+ stesso file.} o se si esegue la rimozione in un processo figlio. Inoltre una
+volta tolto un \textit{file lock} su un file, la rimozione avrà effetto su
+tutti i file descriptor che condividono la stessa voce nella \textit{file
+ table}, e quindi, nel caso di file descriptor ereditati attraverso una
+\func{fork}, anche per processi diversi.
Infine, per evitare che la terminazione imprevista di un processo lasci attivi
dei \textit{file lock}, quando un file viene chiuso il kernel provvede anche a
rimuovere tutti i blocchi ad esso associati. Anche in questo caso occorre
tenere presente cosa succede quando si hanno file descriptor duplicati; in tal
caso infatti il file non verrà effettivamente chiuso (ed il blocco rimosso)
-fintanto che non viene rilasciata la relativa voce nella \itindex{file~table}
-\textit{file table}; e questo avverrà solo quando tutti i file descriptor che
-fanno riferimento alla stessa voce sono stati chiusi. Quindi, nel caso ci
-siano duplicati o processi figli che mantengono ancora aperto un file
-descriptor, il \textit{file lock} non viene rilasciato.
+fintanto che non viene rilasciata la relativa voce nella \textit{file table};
+e questo avverrà solo quando tutti i file descriptor che fanno riferimento
+alla stessa voce sono stati chiusi. Quindi, nel caso ci siano duplicati o
+processi figli che mantengono ancora aperto un file descriptor, il
+\textit{file lock} non viene rilasciato.
\subsection{Il \textit{file locking} POSIX}
\item[\errcode{EDEADLK}] si è richiesto un \textit{lock} su una regione
bloccata da un altro processo che è a sua volta in attesa dello sblocco
di un \textit{lock} mantenuto dal processo corrente; si avrebbe pertanto
- un \itindex{deadlock} \textit{deadlock}. Non è garantito che il sistema
- riconosca sempre questa situazione.
+ un \textit{deadlock}. Non è garantito che il sistema riconosca sempre
+ questa situazione.
\item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima
di poter acquisire un \textit{file lock}.
\item[\errcode{ENOLCK}] il sistema non ha le risorse per il blocco: ci
\begin{figure}[!htb]
\centering \includegraphics[width=9cm]{img/file_lock_dead}
- \caption{Schema di una situazione di \itindex{deadlock} \textit{deadlock}.}
+ \caption{Schema di una situazione di \textit{deadlock}.}
\label{fig:file_flock_dead}
\end{figure}
del processo 2; il processo 1 si bloccherà fintanto che il processo 2 non
rilasci il blocco. Ma cosa accade se il processo 2 nel frattempo tenta a sua
volta di ottenere un lock sulla regione A? Questa è una tipica situazione che
-porta ad un \itindex{deadlock} \textit{deadlock}, dato che a quel punto anche
-il processo 2 si bloccherebbe, e niente potrebbe sbloccare l'altro processo.
-Per questo motivo il kernel si incarica di rilevare situazioni di questo tipo,
-ed impedirle restituendo un errore di \errcode{EDEADLK} alla funzione che
-cerca di acquisire un blocco che porterebbe ad un \itindex{deadlock}
-\textit{deadlock}.
+porta ad un \textit{deadlock}, dato che a quel punto anche il processo 2 si
+bloccherebbe, e niente potrebbe sbloccare l'altro processo. Per questo motivo
+il kernel si incarica di rilevare situazioni di questo tipo, ed impedirle
+restituendo un errore di \errcode{EDEADLK} alla funzione che cerca di
+acquisire un blocco che porterebbe ad un \textit{deadlock}.
Per capire meglio il funzionamento del \textit{file locking} in semantica
POSIX (che differisce alquanto rispetto da quello di BSD, visto
grazie ai campi \var{fl\_start} e \var{fl\_end}. La struttura è comunque la
stessa, solo che in questo caso nel campo \var{fl\_flags} è impostato il bit
\const{FL\_POSIX} ed il campo \var{fl\_file} non viene usato. Il blocco è
-sempre associato \itindex{inode} all'\textit{inode}, solo che in questo caso
-la titolarità non viene identificata con il riferimento ad una voce nella
-\itindex{file~table} \textit{file table}, ma con il valore del \ids{PID} del
-processo.
+sempre associato all'\textit{inode}, solo che in questo caso la titolarità non
+viene identificata con il riferimento ad una voce nella \textit{file table},
+ma con il valore del \ids{PID} del processo.
\begin{figure}[!htb]
\centering \includegraphics[width=12cm]{img/file_posix_lock}
\end{figure}
Quando si richiede un \textit{file lock} il kernel effettua una scansione di
-tutti i blocchi presenti sul file\footnote{scandisce cioè la
- \itindex{linked~list} \textit{linked list} delle strutture
- \kstruct{file\_lock}, scartando automaticamente quelle per cui
- \var{fl\_flags} non è \const{FL\_POSIX}, così che le due interfacce restano
- ben separate.} per verificare se la regione richiesta non si sovrappone ad
-una già bloccata, in caso affermativo decide in base al tipo di blocco, in
-caso negativo il nuovo blocco viene comunque acquisito ed aggiunto alla lista.
+tutti i blocchi presenti sul file\footnote{scandisce cioè la \textit{linked
+ list} delle strutture \kstruct{file\_lock}, scartando automaticamente
+ quelle per cui \var{fl\_flags} non è \const{FL\_POSIX}, così che le due
+ interfacce restano ben separate.} per verificare se la regione richiesta
+non si sovrappone ad una già bloccata, in caso affermativo decide in base al
+tipo di blocco, in caso negativo il nuovo blocco viene comunque acquisito ed
+aggiunto alla lista.
Nel caso di rimozione invece questa viene effettuata controllando che il
\ids{PID} del processo richiedente corrisponda a quello contenuto nel blocco.
opportune verifiche nei processi, questo verrebbe comunque rispettato.
Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
-utilizzo particolare del bit \itindex{sgid~bit} \acr{sgid} dei permessi dei
-file. Se si ricorda quanto esposto in sez.~\ref{sec:file_special_perm}), esso
-viene di norma utilizzato per cambiare il \ids{GID} effettivo con cui viene
-eseguito un programma, ed è pertanto sempre associato alla presenza del
-permesso di esecuzione per il gruppo. Impostando questo bit su un file senza
-permesso di esecuzione in un sistema che supporta il \textit{mandatory
- locking}, fa sì che quest'ultimo venga attivato per il file in questione. In
-questo modo una combinazione dei permessi originariamente non contemplata, in
-quanto senza significato, diventa l'indicazione della presenza o meno del
-\textit{mandatory locking}.\footnote{un lettore attento potrebbe ricordare
- quanto detto in sez.~\ref{sec:file_perm_management} e cioè che il bit
- \acr{sgid} viene cancellato (come misura di sicurezza) quando di scrive su
- un file, questo non vale quando esso viene utilizzato per attivare il
- \textit{mandatory locking}.}
+utilizzo particolare del bit \acr{sgid} dei permessi dei file. Se si ricorda
+quanto esposto in sez.~\ref{sec:file_special_perm}), esso viene di norma
+utilizzato per cambiare il \ids{GID} effettivo con cui viene eseguito un
+programma, ed è pertanto sempre associato alla presenza del permesso di
+esecuzione per il gruppo. Impostando questo bit su un file senza permesso di
+esecuzione in un sistema che supporta il \textit{mandatory locking}, fa sì che
+quest'ultimo venga attivato per il file in questione. In questo modo una
+combinazione dei permessi originariamente non contemplata, in quanto senza
+significato, diventa l'indicazione della presenza o meno del \textit{mandatory
+ locking}.\footnote{un lettore attento potrebbe ricordare quanto detto in
+ sez.~\ref{sec:file_perm_management} e cioè che il bit \acr{sgid} viene
+ cancellato (come misura di sicurezza) quando di scrive su un file, questo
+ non vale quando esso viene utilizzato per attivare il \textit{mandatory
+ locking}.}
L'uso del \textit{mandatory locking} presenta vari aspetti delicati, dato che
neanche l'amministratore può passare sopra ad un \textit{file lock}; pertanto
un processo che blocchi un file cruciale può renderlo completamente
inaccessibile, rendendo completamente inutilizzabile il sistema\footnote{il
- problema si potrebbe risolvere rimuovendo il bit \itindex{sgid~bit}
- \acr{sgid}, ma non è detto che sia così facile fare questa operazione con un
- sistema bloccato.} inoltre con il \textit{mandatory locking} si può
-bloccare completamente un server NFS richiedendo una lettura su un file su cui
-è attivo un blocco. Per questo motivo l'abilitazione del \textit{mandatory
- locking} è di norma disabilitata, e deve essere attivata filesystem per
-filesystem in fase di montaggio, specificando l'apposita opzione di
-\func{mount} riportata in sez.~\ref{sec:filesystem_mounting}, o con l'opzione
-\code{-o mand} per il comando omonimo.
+ problema si potrebbe risolvere rimuovendo il bit \acr{sgid}, ma non è detto
+ che sia così facile fare questa operazione con un sistema bloccato.}
+inoltre con il \textit{mandatory locking} si può bloccare completamente un
+server NFS richiedendo una lettura su un file su cui è attivo un blocco. Per
+questo motivo l'abilitazione del \textit{mandatory locking} è di norma
+disabilitata, e deve essere attivata filesystem per filesystem in fase di
+montaggio, specificando l'apposita opzione di \func{mount} riportata in
+sez.~\ref{sec:filesystem_mounting}, o con l'opzione \code{-o mand} per il
+comando omonimo.
Si tenga presente inoltre che il \textit{mandatory locking} funziona solo
sull'interfaccia POSIX di \func{fcntl}. Questo ha due conseguenze: che non si
Abbiamo visto in sez.~\ref{sec:sig_gen_beha}, affrontando la suddivisione fra
\textit{fast} e \textit{slow} \textit{system call},\index{system~call~lente}
-che in certi casi le funzioni di I/O eseguite su un file descritor possono
+che in certi casi le funzioni di I/O eseguite su un file descriptor possono
bloccarsi indefinitamente. Questo non avviene mai per i file normali, per i
quali le funzioni di lettura e scrittura ritornano sempre subito, ma può
-avvenire per alcuni \index{file!di~dispositivo} file di dispositivo, come ad
-esempio una seriale o un terminale, o con l'uso di file descriptor collegati a
-meccanismi di intercomunicazione come le \textit{pipe} (vedi
-sez.~\ref{sec:ipc_unix}) ed i socket (vedi sez.~\ref{sec:sock_socket_def}). In
-casi come questi ad esempio una operazione di lettura potrebbe bloccarsi se
-non ci sono dati disponibili sul descrittore su cui la si sta effettuando.
+avvenire per alcuni file di dispositivo, come ad esempio una seriale o un
+terminale, o con l'uso di file descriptor collegati a meccanismi di
+intercomunicazione come le \textit{pipe} (vedi sez.~\ref{sec:ipc_unix}) ed i
+socket (vedi sez.~\ref{sec:sock_socket_def}). In casi come questi ad esempio
+una operazione di lettura potrebbe bloccarsi se non ci sono dati disponibili
+sul descrittore su cui la si sta effettuando.
Questo comportamento è alla radice di una delle problematiche più comuni che
ci si trova ad affrontare nella gestione delle operazioni di I/O: la necessità
quella bloccata, mentre nel peggiore dei casi, quando la conclusione
dell'operazione bloccata dipende da quanto si otterrebbe dal file descriptor
``\textsl{disponibile}'', si potrebbe addirittura arrivare ad un
-\itindex{deadlock} \textit{deadlock}.
+\textit{deadlock}.
+
+\itindbeg{polling}
Abbiamo già accennato in sez.~\ref{sec:file_open_close} che è possibile
prevenire questo tipo di comportamento delle funzioni di I/O aprendo un file
immediatamente, restituendo l'errore \errcode{EAGAIN}. L'utilizzo di questa
modalità di I/O permette di risolvere il problema controllando a turno i vari
file descriptor, in un ciclo in cui si ripete l'accesso fintanto che esso non
-viene garantito. Ovviamente questa tecnica, detta \itindex{polling}
-\textit{polling}, è estremamente inefficiente: si tiene costantemente
-impiegata la CPU solo per eseguire in continuazione delle \textit{system call}
-che nella gran parte dei casi falliranno.
+viene garantito. Ovviamente questa tecnica, detta \textit{polling}, è
+estremamente inefficiente: si tiene costantemente impiegata la CPU solo per
+eseguire in continuazione delle \textit{system call} che nella gran parte dei
+casi falliranno.
+
+\itindend{polling}
É appunto per superare questo problema è stato introdotto il concetto di
\textit{I/O multiplexing}, una nuova modalità per la gestione dell'I/O che
Per specificare quali file descriptor si intende selezionare la funzione usa
un particolare oggetto, il \textit{file descriptor set}, identificato dal tipo
\type{fd\_set}, che serve ad identificare un insieme di file descriptor, in
-maniera analoga a come un \itindex{signal~set} \textit{signal set} (vedi
-sez.~\ref{sec:sig_sigset}) identifica un insieme di segnali. Per la
-manipolazione di questi \textit{file descriptor set} si possono usare delle
-opportune macro di preprocessore:
+maniera analoga a come un \textit{signal set} (vedi sez.~\ref{sec:sig_sigset})
+identifica un insieme di segnali. Per la manipolazione di questi \textit{file
+ descriptor set} si possono usare delle opportune macro di preprocessore:
{\centering
\vspace{3pt}
bloccante, quindi anche in caso di \textit{end-of-file}.} il secondo,
\param{writefds}, per verificare la possibilità di effettuare una scrittura ed
il terzo, \param{exceptfds}, per verificare l'esistenza di eccezioni come i
-dati urgenti \itindex{out-of-band} su un socket, (vedi
-sez.~\ref{sec:TCP_urgent_data}).
+dati urgenti su un socket, (vedi sez.~\ref{sec:TCP_urgent_data}).
Dato che in genere non si tengono mai sotto controllo fino a
\const{FD\_SETSIZE} file contemporaneamente, la funzione richiede di
\val{NULL} la funzione attende indefinitamente. Si può specificare anche un
tempo nullo (cioè una struttura \struct{timeval} con i campi impostati a
zero), qualora si voglia semplicemente controllare lo stato corrente dei file
-descriptor, e così può essere utilizzata eseguire il \itindex{polling}
-\textit{polling} su un gruppo di file descriptor. Usare questo argomento con
-tutti i \textit{file descriptor set} vuoti è un modo portabile, disponibile
-anche su sistemi in cui non sono disponibili le funzioni avanzate di
-sez.~\ref{sec:sig_timer_adv}, per tenere un processo in stato di
-\textit{sleep} con precisioni inferiori al secondo.
+descriptor, e così può essere utilizzata eseguire il \textit{polling} su un
+gruppo di file descriptor. Usare questo argomento con tutti i \textit{file
+ descriptor set} vuoti è un modo portabile, disponibile anche su sistemi in
+cui non sono disponibili le funzioni avanzate di sez.~\ref{sec:sig_timer_adv},
+per tenere un processo in stato di \textit{sleep} con precisioni inferiori al
+secondo.
In caso di successo la funzione restituisce il numero di file descriptor
pronti, seguendo il comportamento previsto dallo standard
caso di errore.
Si tenga presente infine che su Linux, in caso di programmazione
-\textit{multithread} se un file descriptor viene chiuso in un altro
+\textit{multi-thread} se un file descriptor viene chiuso in un altro
\textit{thread} rispetto a quello in cui si sta usando \func{select}, questa
non subisce nessun effetto. In altre varianti di sistemi unix-like invece
\func{select} ritorna indicando che il file descriptor è pronto, con
viene sostituita da quella così indicata immediatamente prima di eseguire
l'attesa, e viene poi ripristinata al ritorno della funzione. L'uso
di \param{sigmask} è stato introdotto allo scopo di prevenire possibili
-\textit{race condition} \itindex{race~condition} quando oltre alla presenza di
-dati sui file descriptor come nella \func{select} ordinaria, ci si deve porre
-in attesa anche dell'arrivo di un segnale.
+\textit{race condition} quando oltre alla presenza di dati sui file descriptor
+come nella \func{select} ordinaria, ci si deve porre in attesa anche
+dell'arrivo di un segnale.
Come abbiamo visto in sez.~\ref{sec:sig_example} la tecnica classica per
rilevare l'arrivo di un segnale è quella di utilizzare il gestore per
-impostare una \index{variabili!globali} variabile globale e controllare questa
-nel corpo principale del programma; abbiamo visto in quell'occasione come
-questo lasci spazio a possibili \itindex{race~condition} \textit{race
- condition}, per cui diventa essenziale utilizzare \func{sigprocmask} per
-disabilitare la ricezione del segnale prima di eseguire il controllo e
-riabilitarlo dopo l'esecuzione delle relative operazioni, onde evitare
-l'arrivo di un segnale immediatamente dopo il controllo, che andrebbe perso.
+impostare una variabile globale e controllare questa nel corpo principale del
+programma; abbiamo visto in quell'occasione come questo lasci spazio a
+possibili \textit{race condition}, per cui diventa essenziale utilizzare
+\func{sigprocmask} per disabilitare la ricezione del segnale prima di eseguire
+il controllo e riabilitarlo dopo l'esecuzione delle relative operazioni, onde
+evitare l'arrivo di un segnale immediatamente dopo il controllo, che andrebbe
+perso.
Nel nostro caso il problema si pone quando, oltre al segnale, si devono tenere
sotto controllo anche dei file descriptor con \func{select}, in questo caso si
e si potrebbero eseguire di conseguenza le operazioni relative al segnale e
alla gestione dati con un ciclo del tipo:
\includecodesnip{listati/select_race.c}
-qui però emerge una \itindex{race~condition} \textit{race condition}, perché
-se il segnale arriva prima della chiamata a \func{select}, questa non verrà
-interrotta, e la ricezione del segnale non sarà rilevata.
+qui però emerge una \textit{race condition}, perché se il segnale arriva prima
+della chiamata a \func{select}, questa non verrà interrotta, e la ricezione
+del segnale non sarà rilevata.
Per questo è stata introdotta \func{pselect} che attraverso l'argomento
\param{sigmask} permette di riabilitare la ricezione il segnale
contestualmente all'esecuzione della funzione,\footnote{in Linux però, fino al
kernel 2.6.16, non era presente la relativa \textit{system call}, e la
funzione era implementata nelle \acr{glibc} attraverso \func{select} (vedi
- \texttt{man select\_tut}) per cui la possibilità di \itindex{race~condition}
- \textit{race condition} permaneva; in tale situazione si può ricorrere ad
- una soluzione alternativa, chiamata \itindex{self-pipe trick}
- \textit{self-pipe trick}, che consiste nell'aprire una \textit{pipe} (vedi
- sez.~\ref{sec:ipc_pipes}) ed usare \func{select} sul capo in lettura della
- stessa; si può indicare l'arrivo di un segnale scrivendo sul capo in
- scrittura all'interno del gestore dello stesso; in questo modo anche se il
- segnale va perso prima della chiamata di \func{select} questa lo riconoscerà
- comunque dalla presenza di dati sulla \textit{pipe}.} ribloccandolo non
-appena essa ritorna, così che il precedente codice potrebbe essere riscritto
-nel seguente modo:
+ \texttt{man select\_tut}) per cui la possibilità di \textit{race condition}
+ permaneva; in tale situazione si può ricorrere ad una soluzione alternativa,
+ chiamata \itindex{self-pipe~trick} \textit{self-pipe trick}, che consiste
+ nell'aprire una \textit{pipe} (vedi sez.~\ref{sec:ipc_pipes}) ed usare
+ \func{select} sul capo in lettura della stessa; si può indicare l'arrivo di
+ un segnale scrivendo sul capo in scrittura all'interno del gestore dello
+ stesso; in questo modo anche se il segnale va perso prima della chiamata di
+ \func{select} questa lo riconoscerà comunque dalla presenza di dati sulla
+ \textit{pipe}.} ribloccandolo non appena essa ritorna, così che il
+precedente codice potrebbe essere riscritto nel seguente modo:
\includecodesnip{listati/pselect_norace.c}
in questo caso utilizzando \var{oldmask} durante l'esecuzione di
\func{pselect} la ricezione del segnale sarà abilitata, ed in caso di
\const{POLLIN} & È possibile la lettura.\\
\const{POLLRDNORM}& Sono disponibili in lettura dati normali.\\
\const{POLLRDBAND}& Sono disponibili in lettura dati prioritari.\\
- \const{POLLPRI} & È possibile la lettura di \itindex{out-of-band} dati
- urgenti.\\
+ \const{POLLPRI} & È possibile la lettura di dati urgenti.\\
\hline
\const{POLLOUT} & È possibile la scrittura immediata.\\
\const{POLLWRNORM}& È possibile la scrittura di dati normali.\\
\footnotetext{si tratta di una estensione specifica di Linux, disponibile a
partire dal kernel 2.6.17 definendo la marco \macro{\_GNU\_SOURCE}, che
consente di riconoscere la chiusura in scrittura dell'altro capo di un
- socket, situazione che si viene chiamata appunto \itindex{half-close}
- \textit{half-close} (\textsl{mezza chiusura}) su cui torneremo con maggiori
- dettagli in sez.~\ref{sec:TCP_shutdown}.}
+ socket, situazione che si viene chiamata appunto \textit{half-close}
+ (\textsl{mezza chiusura}) su cui torneremo con maggiori dettagli in
+ sez.~\ref{sec:TCP_shutdown}.}
Il valore \const{POLLMSG} non viene utilizzato ed è definito solo per
compatibilità con l'implementazione di System V che usa i cosiddetti
librerie standard del C visti in sez.~\ref{sec:file_stream}. Da essa derivano
i nomi di alcune costanti poiché per quegli \textit{stream} sono definite tre
classi di dati: \textsl{normali}, \textit{prioritari} ed \textit{urgenti}. In
-Linux la distinzione ha senso solo per i dati urgenti \itindex{out-of-band}
-dei socket (vedi sez.~\ref{sec:TCP_urgent_data}), ma su questo e su come
-\func{poll} reagisce alle varie condizioni dei socket torneremo in
-sez.~\ref{sec:TCP_serv_poll}, dove vedremo anche un esempio del suo utilizzo.
+Linux la distinzione ha senso solo per i dati urgenti dei socket (vedi
+sez.~\ref{sec:TCP_urgent_data}), ma su questo e su come \func{poll} reagisce
+alle varie condizioni dei socket torneremo in sez.~\ref{sec:TCP_serv_poll},
+dove vedremo anche un esempio del suo utilizzo.
Le costanti relative ai diversi tipi di dati normali e prioritari che fanno
riferimento alle implementazioni in stile System V sono \const{POLLRDNORM},
in questo caso non esiste nessuno standard che richieda questo comportamento.
Infine anche per \func{poll} e \func{ppoll} valgono le considerazioni relative
-alla possibilità di avere delle notificazione spurie della disponibilita di
+alla possibilità di avere delle notificazione spurie della disponibilità di
accesso ai file descriptor illustrate per \func{select} in
sez.~\ref{sec:file_select}, che non staremo a ripetere qui.
ha chiuso la connessione o il capo in scrittura
della stessa (vedi
sez.~\ref{sec:TCP_shutdown}).\footnotemark\\
- \const{EPOLLPRI} & Ci sono \itindex{out-of-band} dati urgenti
- disponibili in lettura (analogo di
- \const{POLLPRI}); questa condizione viene comunque
+ \const{EPOLLPRI} & Ci sono dati urgenti disponibili in lettura (analogo
+ di \const{POLLPRI}); questa condizione viene comunque
riportata in uscita, e non è necessaria impostarla
in ingresso.\\
\hline
ed è utile per riconoscere la chiusura di una connessione dall'altro capo di
un socket quando si lavora in modalità \textit{edge triggered}.}
-Il secondo campo, \var{data}, è una \direct{union} che serve a identificare il
+Il secondo campo, \var{data}, è una \dirct{union} che serve a identificare il
file descriptor a cui si intende fare riferimento, ed in astratto può
contenere un valore qualsiasi (specificabile in diverse forme) che ne permetta
una indicazione univoca. Il modo più comune di usarlo però è quello in cui si
Abbiamo visto in sez.~\ref{sec:file_select} come il meccanismo classico delle
notifiche di eventi tramite i segnali, presente da sempre nei sistemi
unix-like, porti a notevoli problemi nell'interazione con le funzioni per
-l'\textit{I/O multiplexing}, tanto che per evitare possibili
-\itindex{race~condition} \textit{race condition} sono state introdotte
-estensioni dello standard POSIX e funzioni apposite come \func{pselect},
-\func{ppoll} e \funcd{epoll\_pwait}.
+l'\textit{I/O multiplexing}, tanto che per evitare possibili \textit{race
+ condition} sono state introdotte estensioni dello standard POSIX e funzioni
+apposite come \func{pselect}, \func{ppoll} e \funcd{epoll\_pwait}.
Benché i segnali siano il meccanismo più usato per effettuare notifiche ai
processi, la loro interfaccia di programmazione, che comporta l'esecuzione di
asincrone in qualunque momento. Questo comporta la necessità di dover
gestire, quando si deve tener conto di entrambi i tipi di eventi, le
interruzioni delle funzioni di attesa sincrone, ed evitare possibili
-\itindex{race~condition} \textit{race conditions}. In sostanza se non ci
-fossero i segnali non ci sarebbe da preoccuparsi, fintanto che si effettuano
-operazioni all'interno di un processo, della non atomicità delle
-\index{system~call~lente} \textit{system call} lente che vengono interrotte e
-devono essere riavviate.
+\textit{race conditions}. In sostanza se non ci fossero i segnali non ci
+sarebbe da preoccuparsi, fintanto che si effettuano operazioni all'interno di
+un processo, della non atomicità delle \index{system~call~lente}
+\textit{system call} lente che vengono interrotte e devono essere riavviate.
Abbiamo visto però in sez.~\ref{sec:sig_real_time} che insieme ai segnali
\textit{real-time} sono state introdotte anche delle interfacce di gestione
\item[\errcode{EINVAL}] il file descriptor \param{fd} non è stato ottenuto
con \func{signalfd} o il valore di \param{flags} non è valido.
\item[\errcode{ENODEV}] il kernel non può montare internamente il
- dispositivo per la gestione anonima degli \itindex{inode} \textit{inode}
+ dispositivo per la gestione anonima degli \textit{inode}
associati al file descriptor.
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare un nuovo file
descriptor di \func{signalfd}.
\var{ssi\_ptr} e \var{ssi\_int} per segnali inviati con \func{sigqueue}.}
Come esempio di questa nuova interfaccia ed anche come esempio di applicazione
-della interfaccia di \itindex{epoll} \textit{epoll}, si è scritto un programma
-elementare che stampi sullo standard output sia quanto viene scritto da terzi
-su una \textit{named fifo}, che l'avvenuta ricezione di alcuni segnali. Il
-codice completo si trova al solito nei sorgenti allegati alla guida (nel file
+della interfaccia di \textit{epoll}, si è scritto un programma elementare che
+stampi sullo \textit{standard output} sia quanto viene scritto da terzi su una
+\textit{named fifo}, che l'avvenuta ricezione di alcuni segnali. Il codice
+completo si trova al solito nei sorgenti allegati alla guida (nel file
\texttt{FifoReporter.c}).
In fig.~\ref{fig:fiforeporter_code_init} si è riportata la parte iniziale del
programma in cui vengono effettuate le varie inizializzazioni necessarie per
-l'uso di \itindex{epoll} \textit{epoll} e \func{signalfd}, a partire
-(\texttt{\small 12-16}) dalla definizione delle varie variabili e strutture
-necessarie. Al solito si è tralasciata la parte dedicata alla decodifica delle
-opzioni che consentono ad esempio di cambiare il nome del file associato alla
-\textit{fifo}.
+l'uso di \textit{epoll} e \func{signalfd}, a partire (\texttt{\small 12-16})
+dalla definizione delle varie variabili e strutture necessarie. Al solito si è
+tralasciata la parte dedicata alla decodifica delle opzioni che consentono ad
+esempio di cambiare il nome del file associato alla \textit{fifo}.
Il primo passo (\texttt{\small 19-20}) è la creazione di un file descriptor
-\texttt{epfd} di \itindex{epoll} \textit{epoll} con \func{epoll\_create} che è
-quello che useremo per il controllo degli altri. É poi necessario
-disabilitare la ricezione dei segnali (nel caso \signal{SIGINT},
-\signal{SIGQUIT} e \signal{SIGTERM}) per i quali si vuole la notifica tramite
-file descriptor. Per questo prima li si inseriscono (\texttt{\small 22-25}) in
-una maschera di segnali \texttt{sigmask} che useremo con (\texttt{\small 26})
+\texttt{epfd} di \textit{epoll} con \func{epoll\_create} che è quello che
+useremo per il controllo degli altri. É poi necessario disabilitare la
+ricezione dei segnali (nel caso \signal{SIGINT}, \signal{SIGQUIT} e
+\signal{SIGTERM}) per i quali si vuole la notifica tramite file
+descriptor. Per questo prima li si inseriscono (\texttt{\small 22-25}) in una
+maschera di segnali \texttt{sigmask} che useremo con (\texttt{\small 26})
\func{sigprocmask} per disabilitarli. Con la stessa maschera si potrà per
passare all'uso (\texttt{\small 28-29}) di \func{signalfd} per abilitare la
notifica sul file descriptor \var{sigfd}. Questo poi (\texttt{\small 30-33})
controllati con \texttt{epfd}.
Occorrerà infine (\texttt{\small 35-38}) creare la \textit{named fifo} se
-questa non esiste ed aprirla per la lettura (\texttt{\small 39-40}); una
-volta fatto questo sarà necessario aggiungere il relativo file descriptor
-(\var{fifofd}) a quelli osservati da \itindex{epoll} \textit{epoll} in maniera
-del tutto analoga a quanto fatto con quello relativo alla notifica dei
-segnali.
+questa non esiste ed aprirla per la lettura (\texttt{\small 39-40}); una volta
+fatto questo sarà necessario aggiungere il relativo file descriptor
+(\var{fifofd}) a quelli osservati da \textit{epoll} in maniera del tutto
+analoga a quanto fatto con quello relativo alla notifica dei segnali.
\begin{figure}[!htb]
\footnotesize \centering
l'argomento \param{flag} non è valido, o è diverso da zero per kernel
precedenti il 2.6.27.
\item[\errcode{ENODEV}] il kernel non può montare internamente il
- dispositivo per la gestione anonima degli \itindex{inode} \textit{inode}
- associati al file descriptor.
+ dispositivo per la gestione anonima degli \textit{inode} associati al file
+ descriptor.
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare un nuovo file
descriptor di \func{signalfd}.
\end{errlist}
Per questo motivo Stevens, ed anche le pagine di manuale di Linux, chiamano
questa modalità ``\textit{Signal driven I/O}''. Si tratta di un'altra
-modalità di gestione dell'I/O, alternativa all'uso di \itindex{epoll}
+modalità di gestione dell'I/O, alternativa all'uso di
\textit{epoll},\footnote{anche se le prestazioni ottenute con questa tecnica
sono inferiori, il vantaggio è che questa modalità è utilizzabile anche con
kernel che non supportano \textit{epoll}, come quelli della serie 2.4,
all'origine di Unix i soli programmi che potevano avere una tale esigenza
erano i demoni, attenendosi a uno dei criteri base della progettazione, che
era di far fare al kernel solo le operazioni strettamente necessarie e
-lasciare tutto il resto a processi in user space, non era stata prevista
-nessuna funzionalità di notifica.
+lasciare tutto il resto a processi in \textit{user space}, non era stata
+prevista nessuna funzionalità di notifica.
Visto però il crescente interesse nei confronti di una funzionalità di questo
tipo, che è molto richiesta specialmente nello sviluppo dei programmi ad
filesystem, sono state successivamente introdotte delle estensioni che
permettessero la creazione di meccanismi di notifica più efficienti dell'unica
soluzione disponibile con l'interfaccia tradizionale, che è quella del
-\itindex{polling} \textit{polling}.
+\textit{polling}.
Queste nuove funzionalità sono delle estensioni specifiche, non
standardizzate, che sono disponibili soltanto su Linux (anche se altri kernel
(\textit{pipe} e dispositivi sono quindi esclusi). Inoltre un processo non
privilegiato può ottenere un \textit{lease} soltanto per un file appartenente
ad un \ids{UID} corrispondente a quello del processo. Soltanto un processo con
-privilegi di amministratore (cioè con la \itindex{capabilities} capability
-\const{CAP\_LEASE}, vedi sez.~\ref{sec:proc_capabilities}) può acquisire
-\textit{lease} su qualunque file.
+privilegi di amministratore (cioè con la capacità \const{CAP\_LEASE}, vedi
+sez.~\ref{sec:proc_capabilities}) può acquisire \textit{lease} su qualunque
+file.
Se su un file è presente un \textit{lease} quando il \textit{lease breaker}
esegue una \func{truncate} o una \func{open} che confligge con
\const{IN\_ACCESS} &$\bullet$& C'è stato accesso al file in
lettura.\\
\const{IN\_ATTRIB} &$\bullet$& Ci sono stati cambiamenti sui dati
- dell'\itindex{inode} \textit{inode}
+ dell'\textit{inode}
(o sugli attributi estesi, vedi
sez.~\ref{sec:file_xattr}).\\
\const{IN\_CLOSE\_WRITE} &$\bullet$& È stato chiuso un file aperto in
Infine due campi \var{name} e \var{len} sono utilizzati soltanto quando
l'evento è relativo ad un file presente in una directory posta sotto
osservazione, in tal caso essi contengono rispettivamente il nome del file
-(come \itindsub{pathname}{relativo} \textit{pathname} relativo alla directory
-osservata) e la relativa dimensione in byte. Il campo \var{name} viene sempre
-restituito come stringa terminata da NUL, con uno o più zeri di terminazione,
-a seconda di eventuali necessità di allineamento del risultato, ed il valore
-di \var{len} corrisponde al totale della dimensione di \var{name}, zeri
-aggiuntivi compresi. La stringa con il nome del file viene restituita nella
-lettura subito dopo la struttura \struct{inotify\_event}; questo significa che
-le dimensioni di ciascun evento di \textit{inotify} saranno pari a
-\code{sizeof(\struct{inotify\_event}) + len}.
+(come \textit{pathname} relativo alla directory osservata) e la relativa
+dimensione in byte. Il campo \var{name} viene sempre restituito come stringa
+terminata da NUL, con uno o più zeri di terminazione, a seconda di eventuali
+necessità di allineamento del risultato, ed il valore di \var{len} corrisponde
+al totale della dimensione di \var{name}, zeri aggiuntivi compresi. La stringa
+con il nome del file viene restituita nella lettura subito dopo la struttura
+\struct{inotify\_event}; questo significa che le dimensioni di ciascun evento
+di \textit{inotify} saranno pari a \code{sizeof(\struct{inotify\_event}) +
+ len}.
Vediamo allora un esempio dell'uso dell'interfaccia di \textit{inotify} con un
semplice programma che permette di mettere sotto osservazione uno o più file e
rispetto a quelle usate normalmente.
In generale questa interfaccia è completamente astratta e può essere
-implementata sia direttamente nel kernel che in user space attraverso l'uso di
-\itindex{thread} \textit{thread}. Per le versioni del kernel meno recenti
-esiste una implementazione di questa interfaccia fornita completamente delle
-\acr{glibc} a partire dalla versione 2.1, che è realizzata completamente in
-user space, ed è accessibile linkando i programmi con la libreria
+implementata sia direttamente nel kernel che in \textit{user space} attraverso
+l'uso di \textit{thread}. Per le versioni del kernel meno recenti esiste una
+implementazione di questa interfaccia fornita completamente delle \acr{glibc}
+a partire dalla versione 2.1, che è realizzata completamente in \textit{user
+ space}, ed è accessibile linkando i programmi con la libreria
\file{librt}. A partire dalla versione 2.5.32 è stato introdotto nel kernel
una nuova infrastruttura per l'I/O asincrono, ma ancora il supporto è parziale
ed insufficiente ad implementare tutto l'AIO POSIX.
operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari
campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la
richiesta. Questo comporta che non si devono usare per \param{aiocbp}
-\index{variabili!automatiche} variabili automatiche e che non si deve
-riutilizzare la stessa struttura per un'altra operazione fintanto che la
-precedente non sia stata ultimata. In generale per ogni operazione si deve
-utilizzare una diversa struttura \struct{aiocb}.
+variabili automatiche e che non si deve riutilizzare la stessa struttura per
+un'altra operazione fintanto che la precedente non sia stata ultimata. In
+generale per ogni operazione si deve utilizzare una diversa struttura
+\struct{aiocb}.
Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o
\func{aio\_write} non implica che le operazioni siano state effettivamente
\label{sec:file_memory_map}
\itindbeg{memory~mapping}
+
Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
rispetto a quella classica vista in sez.~\ref{sec:file_unix_interface}, è il
cosiddetto \textit{memory-mapped I/O}, che attraverso il meccanismo della
-\textsl{paginazione} \index{paginazione} usato dalla memoria virtuale (vedi
+\textsl{paginazione} usato dalla memoria virtuale (vedi
sez.~\ref{sec:proc_mem_gen}) permette di \textsl{mappare} il contenuto di un
file in una sezione dello spazio di indirizzi del processo che lo ha allocato.
database effettuare accessi ai dati in maniera pressoché casuale, mentre un
riproduttore audio o video eseguirà per lo più letture sequenziali.
+\itindend{memory~mapping}
+
Per migliorare le prestazioni a seconda di queste modalità di accesso è
disponibile una apposita funzione, \funcd{madvise},\footnote{tratteremo in
sez.~\ref{sec:file_fadvise} le funzioni che consentono di ottimizzare
l'accesso ai file con l'interfaccia classica.} che consente di fornire al
-kernel delle indicazioni su dette modalità, così che possano essere adottate
-le opportune strategie di ottimizzazione. Il suo prototipo è:
+kernel delle indicazioni su come un processo intende accedere ad un segmento
+di memoria, anche al di là delle mappature dei file, così che possano essere
+adottate le opportune strategie di ottimizzazione. Il suo prototipo è:
\begin{funcproto}{
\fhead{sys/mman.h}
\fdecl{int madvise(void *start, size\_t length, int advice)}
-\fdesc{Fornisce indicazioni sull'uso previsto di un \textit{memory mapping}.}
+\fdesc{Fornisce indicazioni sull'uso previsto di un segmento di memoria.}
}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
\item[\errcode{EINVAL}] \param{start} non è allineato alla dimensione di
una pagina, \param{length} ha un valore negativo, o \param{advice} non è
un valore valido, o si è richiesto il rilascio (con
- \const{MADV\_DONTNEED}) di pagine bloccate o condivise.
+ \const{MADV\_DONTNEED}) di pagine bloccate o condivise o si è usato
+ \const{MADV\_MERGEABLE} o \const{MADV\_UNMERGEABLE} ma il kernel non è
+ stato compilato per il relativo supporto.
\item[\errcode{EIO}] la paginazione richiesta eccederebbe i limiti (vedi
sez.~\ref{sec:sys_resource_limit}) sulle pagine residenti in memoria del
processo (solo in caso di \const{MADV\_WILLNEED}).
ed inoltre \errval{EAGAIN} e \errval{ENOSYS} nel loro significato generico.}
\end{funcproto}
-
La sezione di memoria sulla quale si intendono fornire le indicazioni deve
essere indicata con l'indirizzo iniziale \param{start} e l'estensione
\param{length}, il valore di \param{start} deve essere allineato,
L'indicazione viene espressa dall'argomento \param{advice} che deve essere
specificato con uno dei valori riportati in
tab.~\ref{tab:madvise_advice_values}; si tenga presente che i valori indicati
-nella seconda parte sono specifici di Linux e non sono previsti dallo standard
-POSIX.1b.
+nella seconda parte della tabella sono specifici di Linux e non sono previsti
+dallo standard POSIX.1b. La funzione non ha, tranne il caso di
+\const{MADV\_DONTFORK}, nessun effetto sul comportamento di un programma, ma
+può influenzarne le prestazioni fornendo al kernel indicazioni sulle esigenze
+dello stesso, così che sia possibile scegliere le opportune strategie per la
+gestione del \textit{read-ahead} (vedi sez.~\ref{sec:file_fadvise}) e del
+caching dei dati.
-\begin{table}[htb]
+\begin{table}[!htb]
\centering
\footnotesize
\begin{tabular}[c]{|l|p{10 cm}|}
\func{madvise}.\\
\const{MADV\_RANDOM} & ci si aspetta un accesso casuale all'area
indicata, pertanto l'applicazione di una lettura
- anticipata con il meccanismo del \textit{read-ahead} (vedi
+ anticipata con il meccanismo del
+ \textit{read-ahead} (vedi
sez.~\ref{sec:file_fadvise}) è di
scarsa utilità e verrà disabilitata.\\
\const{MADV\_SEQUENTIAL}& ci si aspetta un accesso sequenziale al file,
pertanto l'applicazione del \textit{read-ahead}
deve essere incentivata.\\
\hline
- \const{MADV\_REMOVE} & libera un intervallo di pagine di memoria ed il
- relativo supporto sottostante; è supportato
- soltanto sui filesystem in RAM \textit{tmpfs} e
- \textit{shmfs} se usato su altri tipi di
- filesystem causa un errore di \errcode{ENOSYS}
- (dal kernel 2.6.16).\\
+ \const{MADV\_DONTDUMP}& esclude da un \textit{core dump} (vedi
+ sez.~\ref{sec:sig_standard}) le pagine
+ specificate, viene usato per evitare di scrivere
+ su disco dati relativi a zone di memoria che si sa
+ non essere utili in un \textit{core dump}.\\
+ \const{MADV\_DODUMP} & rimuove l'effetto della precedente
+ \const{MADV\_DONTDUMP} (dal kernel 3.4).\\
\const{MADV\_DONTFORK}& impedisce che l'intervallo specificato venga
ereditato dal processo figlio dopo una
\func{fork}; questo consente di evitare che il
meccanismo del \textit{copy on write} effettui la
rilocazione delle pagine quando il padre scrive
- sull'area di memoria dopo la \func{fork}, cosa che può
- causare problemi per l'hardware che esegue
+ sull'area di memoria dopo la \func{fork}, cosa che
+ può causare problemi per l'hardware che esegue
operazioni in DMA su quelle pagine (dal kernel
2.6.16).\\
\const{MADV\_DOFORK} & rimuove l'effetto della precedente
\const{MADV\_DONTFORK} (dal kernel 2.6.16).\\
- \const{MADV\_MERGEABLE}& marca la pagina come accorpabile (indicazione
+ \const{MADV\_HUGEPAGE}& abilita il meccanismo delle \textit{Transparent
+ Huge Page} (vedi sez.~\ref{sec:huge_pages})
+ sulla regione indicata; se questa è allineata
+ alle relative dimensioni il kernel alloca
+ direttamente delle \textit{huge page}; è
+ utilizzabile solo con mappature anomime private
+ (dal kernel 2.6.38).\\
+ \const{MADV\_NOHUGEPAGE}& impedisce che la regione indicata venga
+ collassata in eventuali \textit{huge page} (dal
+ kernel 2.6.38).\\
+ \const{MADV\_HWPOISON} &opzione ad uso di debug per verificare codice
+ che debba gestire errori nella gestione della
+ memoria; richiede una apposita opzione di
+ compilazione del kernel, privilegi amministrativi
+ (la capacità \const{CAP\_SYS\_ADMIN}) e provoca
+ l'emissione di un segnale di \const{SIGBUS} dal
+ programma chiamante e rimozione della mappatura
+ (dal kernel 2.6.32).\\
+ \const{MADV\_SOFT\_OFFLINE}&opzione utilizzata per il debug del
+ codice di verifica degli errori di gestione
+ memoria, richiede una apposita opzione di
+ compilazione (dal kernel 2.6.33).\\
+ \const{MADV\_MERGEABLE}& marca la pagina come accorpabile, indicazione
principalmente ad uso dei sistemi di
- virtualizzazione).\footnotemark\\
- \const{MADV\_UNMERGEABLE}& \\
+ virtualizzazione\footnotemark (dal kernel 2.6.32).\\
+ \const{MADV\_REMOVE} & libera un intervallo di pagine di memoria ed il
+ relativo supporto sottostante; è supportato
+ soltanto sui filesystem in RAM \textit{tmpfs} e
+ \textit{shmfs} se usato su altri tipi di
+ filesystem causa un errore di \errcode{ENOSYS}
+ (dal kernel 2.6.16).\\
+ \const{MADV\_UNMERGEABLE}& rimuove l'effetto della precedente
+ \const{MADV\_MERGEABLE} (dal kernel 2.6.32). \\
\hline
\end{tabular}
\caption{Valori dell'argomento \param{advice} di \func{madvise}.}
\label{tab:madvise_advice_values}
\end{table}
-\footnotetext{.}
-
\footnotetext{a partire dal kernel 2.6.32 è stato introdotto un meccanismo che
identifica pagine di memoria identiche e le accorpa in una unica pagina
(soggetta al \textit{copy-on-write} per successive modifiche); per evitare
la loro occupazione di memoria, ma il meccanismo può essere usato anche in
altre applicazioni in cui sian presenti numerosi processi che usano gli
stessi dati; per maggiori dettagli si veda
- \href{http://kernelnewbies.org/Linux_2_6_32\#head-d3f32e41df508090810388a57efce73f52660ccb}{\texttt{http://kernelnewbies.org/Linux\_2\_6\_32}}.}
-
-La funzione non ha, tranne il caso di \const{MADV\_DONTFORK}, nessun effetto
-sul comportamento di un programma, ma può influenzarne le prestazioni fornendo
-al kernel indicazioni sulle esigenze dello stesso, così che sia possibile
-scegliere le opportune strategie per la gestione del \itindex{read-ahead}
-\textit{read-ahead} e del caching dei dati. A differenza da quanto specificato
-nello standard POSIX.1b, per il quale l'uso di \func{madvise} è a scopo
-puramente indicativo, Linux considera queste richieste come imperative, per
-cui ritorna un errore qualora non possa soddisfarle.\footnote{questo
- comportamento differisce da quanto specificato nello standard.}
+ \href{http://kernelnewbies.org/Linux_2_6_32\#head-d3f32e41df508090810388a57efce73f52660ccb}{\texttt{http://kernelnewbies.org/Linux\_2\_6\_32}}
+ e la documentazione nei sorgenti del kernel
+ (\texttt{Documentation/vm/ksm.txt}).}
+
+
+A differenza da quanto specificato nello standard POSIX.1b, per il quale l'uso
+di \func{madvise} è a scopo puramente indicativo, Linux considera queste
+richieste come imperative, per cui ritorna un errore qualora non possa
+soddisfarle; questo comportamento differisce da quanto specificato nello
+standard.
+
+Nello standard POSIX.1-2001 è prevista una ulteriore funzione
+\funcd{posix\_madvise} che su Linux viene reimplementata utilizzando
+\func{madvise}; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/mman.h}
+\fdecl{int posix\_madvise(void *start, size\_t lenght, int advice)}
+\fdesc{Fornisce indicazioni sull'uso previsto di un segmento di memoria.}
+}
+
+{La funzione ritorna $0$ in caso di successo ed un valore positivo per un
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] \param{start} non è allineato alla dimensione di
+ una pagina, \param{length} ha un valore negativo, o \param{advice} non è
+ un valore valido.
+ \item[\errcode{ENOMEM}] gli indirizzi specificati non sono nello spazio di
+ indirizzi del processo.
+ \end{errlist}
+}
+\end{funcproto}
+
+Gli argomenti \param{start} e \param{lenght} hanno lo stesso identico
+significato degli analoghi di \func{madvise}, a cui si rimanda per la loro
+descrizione ma a differenza di quanto indicato dallo standard per questa
+funzione, su Linux un valore nullo di \param{len} è consentito.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{POSIX\_MADV\_DONTNEED}& analogo a \const{MADV\_DONTNEED}.\\
+ \const{POSIX\_MADV\_NORMAL} & identico a \const{MADV\_NORMAL}.\\
+ \const{POSIX\_MADV\_RANDOM} & identico a \const{MADV\_RANDOM}.\\
+ \const{POSIX\_MADV\_SEQUENTIAL}& identico a \const{MADV\_SEQUENTIAL}.\\
+ \const{POSIX\_MADV\_WILLNEED}& identico a \const{MADV\_WILLNEED}.\\
+ \hline
+ \end{tabular}
+ \caption{Valori dell'argomento \param{advice} di \func{posix\_madvise}.}
+ \label{tab:posix_madvise_advice_values}
+\end{table}
+
+
+L'argomento \param{advice} invece può assumere solo i valori indicati in
+tab.~\ref{tab:posix_madvise_advice_values}, che riflettono gli analoghi di
+\func{madvise}, con lo stesso effetto per tutti tranne
+\const{POSIX\_MADV\_DONTNEED}. Infatti a partire dalle \acr{glibc} 2.6
+\const{POSIX\_MADV\_DONTNEED} viene ignorato, in quanto l'uso del
+corrispondente \const{MADV\_DONTNEED} di \func{madvise} ha, per la semantica
+imperativa, l'effetto immediato di far liberare le pagine da parte del kernel,
+che viene considerato distruttivo.
-\itindend{memory~mapping}
\subsection{I/O vettorizzato: \func{readv} e \func{writev}}
\label{sec:file_multiple_io}
-Un caso abbastanza comune è quello in cui ci si trova a dover eseguire una
-serie multipla di operazioni di I/O, come una serie di letture o scritture di
-vari buffer. Un esempio tipico è quando i dati sono strutturati nei campi di
-una struttura ed essi devono essere caricati o salvati su un file. Benché
-l'operazione sia facilmente eseguibile attraverso una serie multipla di
-chiamate a \func{read} e \func{write}, ci sono casi in cui si vuole poter
-contare sulla atomicità delle operazioni.
+Una seconda modalità di I/O diversa da quella ordinaria è il cosiddetto
+\textsl{I/O vettorizzato}, che nasce per rispondere al caso abbastanza comune
+in cui ci si trova nell'esigenza di dover eseguire una serie multipla di
+operazioni di I/O, come una serie di letture o scritture di vari buffer. Un
+esempio tipico è quando i dati sono strutturati nei campi di una struttura ed
+essi devono essere caricati o salvati su un file. Benché l'operazione sia
+facilmente eseguibile attraverso una serie multipla di chiamate a \func{read}
+e \func{write}, ci sono casi in cui si vuole poter contare sulla atomicità
+delle operazioni di lettura e scrittura rispetto all'esecuzione del programma.
Per questo motivo fino da BSD 4.2 vennero introdotte delle nuove
\textit{system call} che permettessero di effettuare con una sola chiamata una
-serie di letture o scritture su una serie di buffer, con quello che viene
-normalmente chiamato \textsl{I/O vettorizzato}. Queste funzioni sono
+serie di letture da, o scritture su, una serie di buffer, quello che poi venne
+chiamato \textsl{I/O vettorizzato}. Queste funzioni di sistema sono
\funcd{readv} e \funcd{writev},\footnote{in Linux le due funzioni sono riprese
da BSD4.4, esse sono previste anche dallo standard POSIX.1-2001.} ed i
relativi prototipi sono:
-\begin{functions}
- \headdecl{sys/uio.h}
-
- \funcdecl{int readv(int fd, const struct iovec *vector, int count)}
- \funcdecl{int writev(int fd, const struct iovec *vector, int count)}
- Eseguono rispettivamente una lettura o una scrittura vettorizzata.
-
- \bodydesc{Le funzioni restituiscono il numero di byte letti o scritti in
- caso di successo, e -1 in caso di errore, nel qual caso \var{errno}
- assumerà uno dei valori:
+
+\begin{funcproto}{
+\fhead{sys/uio.h}
+\fdecl{int readv(int fd, const struct iovec *vector, int count)}
+\fdecl{int writev(int fd, const struct iovec *vector, int count)}
+\fdesc{Eseguono rispettivamente una lettura o una scrittura vettorizzata.}
+}
+
+{Le funzioni ritornano il numero di byte letti o scritti in caso di successo e
+ $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] si è specificato un valore non valido per uno degli
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per uno degli
argomenti (ad esempio \param{count} è maggiore di \const{IOV\_MAX}).
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
- di avere eseguito una qualunque lettura o scrittura.
- \item[\errcode{EAGAIN}] \param{fd} è stato aperto in modalità non bloccante e
- non ci sono dati in lettura.
- \item[\errcode{EOPNOTSUPP}] la coda delle richieste è momentaneamente piena.
\end{errlist}
- ed anche \errval{EISDIR}, \errval{EBADF}, \errval{ENOMEM}, \errval{EFAULT}
- (se non sono stati allocati correttamente i buffer specificati nei campi
- \var{iov\_base}), più gli eventuali errori delle funzioni di lettura e
- scrittura eseguite su \param{fd}.}
-\end{functions}
+ più tutti i valori, con lo stesso significato, che possono risultare
+ dalle condizioni di errore di \func{read} e \func{write}.
+ }
+\end{funcproto}
+
Entrambe le funzioni usano una struttura \struct{iovec}, la cui definizione è
riportata in fig.~\ref{fig:file_iovec}, che definisce dove i dati devono
bit dell'argomento \param{offset}, che varia a seconda delle architetture,
ma queste differenze vengono gestite dalle funzioni di librerie di libreria
che mantengono l'interfaccia delle analoghe tratte da BSD.}
-\begin{functions}
- \headdecl{sys/uio.h}
-
- \funcdecl{int preadv(int fd, const struct iovec *vector, int count, off\_t
+
+
+\begin{funcproto}{
+\fhead{sys/uio.h}
+\fdecl{int preadv(int fd, const struct iovec *vector, int count, off\_t
offset)}
- \funcdecl{int pwritev(int fd, const struct iovec *vector, int count, off\_t
+\fdecl{int pwritev(int fd, const struct iovec *vector, int count, off\_t
offset)}
+\fdesc{Eseguono una lettura o una scrittura vettorizzata a partire da una data
+ posizione sul file.}
+}
- Eseguono una lettura o una scrittura vettorizzata a partire da una data
- posizione sul file.
-
- \bodydesc{Le funzioni hanno gli stessi valori di ritorno delle
- corrispondenti \func{readv} e \func{writev}; anche gli eventuali errori
- sono gli stessi già visti in precedenza, ma ad essi si possono aggiungere
- per \var{errno} anche i valori:
- \begin{errlist}
- \item[\errcode{EOVERFLOW}] \param{offset} ha un valore che non può essere
- usato come \type{off\_t}.
- \item[\errcode{ESPIPE}] \param{fd} è associato ad un socket o una
- \textit{pipe}.
- \end{errlist}
+{ Le funzioni hanno gli stessi valori di ritorno delle corrispondenti
+ \func{readv} e \func{writev} ed anche gli eventuali errori sono gli stessi,
+ con in più quelli che si possono ottenere dalle possibili condizioni di
+ errore di \func{lseek}.
}
-\end{functions}
+\end{funcproto}
Le due funzioni eseguono rispettivamente una lettura o una scrittura
vettorizzata a partire dalla posizione \param{offset} sul file indicato
dell'ulteriore argomento il comportamento delle funzioni è identico alle
precedenti \func{readv} e \func{writev}.
-Con l'uso di queste funzioni si possono evitare eventuali
-\itindex{race~condition} \textit{race condition} quando si deve eseguire la
-una operazione di lettura e scrittura vettorizzata a partire da una certa
-posizione su un file, mentre al contempo si possono avere in concorrenza
-processi che utilizzano lo stesso file descriptor (si ricordi quanto visto in
-sez.~\ref{sec:file_adv_func}) con delle chiamate a \func{lseek}.
+Con l'uso di queste funzioni si possono evitare eventuali \textit{race
+ condition} quando si deve eseguire la una operazione di lettura e scrittura
+vettorizzata a partire da una certa posizione su un file, mentre al contempo
+si possono avere in concorrenza processi che utilizzano lo stesso file
+descriptor (si ricordi quanto visto in sez.~\ref{sec:file_adv_func}) con delle
+chiamate a \func{lseek}.
Benché il kernel ottimizzi la gestione di questo processo quando si ha a che
fare con file normali, in generale quando i dati da trasferire sono molti si
pone il problema di effettuare trasferimenti di grandi quantità di dati da
-kernel space a user space e all'indietro, quando in realtà potrebbe essere più
-efficiente mantenere tutto in kernel space. Tratteremo in questa sezione
-alcune funzioni specialistiche che permettono di ottimizzare le prestazioni in
-questo tipo di situazioni.
+\textit{kernel space} a \textit{user space} e all'indietro, quando in realtà
+potrebbe essere più efficiente mantenere tutto in \textit{kernel
+ space}. Tratteremo in questa sezione alcune funzioni specialistiche che
+permettono di ottimizzare le prestazioni in questo tipo di situazioni.
La prima funzione che è stata ideata per ottimizzare il trasferimento dei dati
-fra due file descriptor è \func{sendfile};\footnote{la funzione è stata
+fra due file descriptor è \func{sendfile}.\footnote{la funzione è stata
introdotta con i kernel della serie 2.2, e disponibile dalle \acr{glibc}
- 2.1.} la funzione è presente in diverse versioni di Unix,\footnote{la si
- ritrova ad esempio in FreeBSD, HPUX ed altri Unix.} ma non è presente né in
-POSIX.1-2001 né in altri standard,\footnote{pertanto si eviti di utilizzarla
- se si devono scrivere programmi portabili.} per cui per essa vengono
-utilizzati prototipi e semantiche differenti; nel caso di Linux il prototipo
-di \funcd{sendfile} è:
-\begin{functions}
- \headdecl{sys/sendfile.h}
-
- \funcdecl{ssize\_t sendfile(int out\_fd, int in\_fd, off\_t *offset, size\_t
- count)}
-
- Copia dei dati da un file descriptor ad un altro.
+ 2.1.} La funzione è presente in diverse versioni di Unix (la si ritrova ad
+esempio in FreeBSD, HPUX ed altri Unix) ma non è presente né in POSIX.1-2001
+né in altri standard (pertanto si eviti di utilizzarla se si devono scrivere
+programmi portabili) per cui per essa vengono utilizzati prototipi e
+semantiche differenti. Nel caso di Linux il prototipo di \funcd{sendfile} è:
- \bodydesc{La funzione restituisce il numero di byte trasferiti in caso di
- successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
- dei valori:
- \begin{errlist}
+
+\begin{funcproto}{
+\fhead{sys/sendfile.h}
+\fdecl{ssize\_t sendfile(int out\_fd, int in\_fd, off\_t *offset, size\_t
+ count)}
+\fdesc{Copia dei dati da un file descriptor ad un altro.}
+}
+
+{La funzione ritorna il numero di byte trasferiti in caso di successo e $-1$
+ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
\item[\errcode{EAGAIN}] si è impostata la modalità non bloccante su
\param{out\_fd} e la scrittura si bloccherebbe.
\item[\errcode{EINVAL}] i file descriptor non sono validi, o sono bloccati
\item[\errcode{EIO}] si è avuto un errore di lettura da \param{in\_fd}.
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per la lettura da
\param{in\_fd}.
- \end{errlist}
- ed inoltre \errcode{EBADF} e \errcode{EFAULT}.
- }
-\end{functions}
+ \end{errlist}
+ ed inoltre \errcode{EBADF} e \errcode{EFAULT} nel loro significato
+ generico.}
+\end{funcproto}
La funzione copia direttamente \param{count} byte dal file descriptor
-\param{in\_fd} al file descriptor \param{out\_fd}; in caso di successo
+\param{in\_fd} al file descriptor \param{out\_fd}. In caso di successo la
funzione ritorna il numero di byte effettivamente copiati da \param{in\_fd} a
-\param{out\_fd} o $-1$ in caso di errore; come le ordinarie \func{read} e
-\func{write} questo valore può essere inferiore a quanto richiesto con
-\param{count}.
+\param{out\_fd} e come per le ordinarie \func{read} e \func{write} questo
+valore può essere inferiore a quanto richiesto con \param{count}.
Se il puntatore \param{offset} è nullo la funzione legge i dati a partire
dalla posizione corrente su \param{in\_fd}, altrimenti verrà usata la
nullo la posizione corrente sul file sarà aggiornata tenendo conto dei byte
letti da \param{in\_fd}.
-Fino ai kernel della serie 2.4 la funzione è utilizzabile su un qualunque file
-descriptor, e permette di sostituire la invocazione successiva di una
+Fino ai kernel della serie 2.4 la funzione era utilizzabile su un qualunque
+file descriptor, e permetteva di sostituire la invocazione successiva di una
\func{read} e una \func{write} (e l'allocazione del relativo buffer) con una
-sola chiamata a \funcd{sendfile}. In questo modo si può diminuire il numero di
-chiamate al sistema e risparmiare in trasferimenti di dati da kernel space a
-user space e viceversa. La massima utilità della funzione si ha comunque per
-il trasferimento di dati da un file su disco ad un socket di
-rete,\footnote{questo è il caso classico del lavoro eseguito da un server web,
- ed infatti Apache ha una opzione per il supporto esplicito di questa
- funzione.} dato che in questo caso diventa possibile effettuare il
-trasferimento diretto via DMA dal controller del disco alla scheda di rete,
-senza neanche allocare un buffer nel kernel,\footnote{il meccanismo è detto
- \textit{zerocopy} in quanto i dati non vengono mai copiati dal kernel, che
- si limita a programmare solo le operazioni di lettura e scrittura via DMA.}
+sola chiamata a \funcd{sendfile}. In questo modo si poteva diminuire il numero
+di chiamate al sistema e risparmiare in trasferimenti di dati da
+\textit{kernel space} a \textit{user space} e viceversa. La massima utilità
+della funzione si ottiene comunque per il trasferimento di dati da un file su
+disco ad un socket di rete,\footnote{questo è il caso classico del lavoro
+ eseguito da un server web, ed infatti Apache ha una opzione per il supporto
+ esplicito di questa funzione.} dato che in questo caso diventa possibile
+effettuare il trasferimento diretto via DMA dal controller del disco alla
+scheda di rete, senza neanche allocare un buffer nel kernel (il meccanismo è
+detto \textit{zerocopy} in quanto i dati non vengono mai copiati dal kernel,
+che si limita a programmare solo le operazioni di lettura e scrittura via DMA)
ottenendo la massima efficienza possibile senza pesare neanche sul processore.
-In seguito però ci si è accorti che, fatta eccezione per il trasferimento
+In seguito però ci si accorse che, fatta eccezione per il trasferimento
diretto da file a socket, non sempre \func{sendfile} comportava miglioramenti
significativi delle prestazioni rispetto all'uso in sequenza di \func{read} e
-\func{write},\footnote{nel caso generico infatti il kernel deve comunque
- allocare un buffer ed effettuare la copia dei dati, e in tal caso spesso il
- guadagno ottenibile nel ridurre il numero di chiamate al sistema non
- compensa le ottimizzazioni che possono essere fatte da una applicazione in
- user space che ha una conoscenza diretta su come questi sono strutturati.} e
-che anzi in certi casi si potevano avere anche dei peggioramenti. Questo ha
+\func{write}. Nel caso generico infatti il kernel deve comunque allocare un
+buffer ed effettuare la copia dei dati, e in tal caso spesso il guadagno
+ottenibile nel ridurre il numero di chiamate al sistema non compensa le
+ottimizzazioni che possono essere fatte da una applicazione in \textit{user
+ space} che ha una conoscenza diretta su come questi sono strutturati, per
+cui in certi casi si potevano avere anche dei peggioramenti. Questo ha
portato, per i kernel della serie 2.6,\footnote{per alcune motivazioni di
questa scelta si può fare riferimento a quanto illustrato da Linus Torvalds
in \url{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}.}
alla decisione di consentire l'uso della funzione soltanto quando il file da
cui si legge supporta le operazioni di \textit{memory mapping} (vale a dire
non è un socket) e quello su cui si scrive è un socket; in tutti gli altri
-casi l'uso di \func{sendfile} darà luogo ad un errore di \errcode{EINVAL}.
+casi l'uso di \func{sendfile} da luogo ad un errore di \errcode{EINVAL}.
Nonostante ci possano essere casi in cui \func{sendfile} non migliora le
prestazioni, resta il dubbio se la scelta di disabilitarla sempre per il
di prestazioni infatti si può sempre fare ricorso al metodo ordinario, ma
lasciare a disposizione la funzione consentirebbe se non altro di semplificare
la gestione della copia dei dati fra file, evitando di dover gestire
-l'allocazione di un buffer temporaneo per il loro trasferimento.
-
-Questo dubbio si può comunque ritenere superato con l'introduzione, avvenuta a
-partire dal kernel 2.6.17, della nuova \textit{system call} \func{splice}. Lo
-scopo di questa funzione è quello di fornire un meccanismo generico per il
-trasferimento di dati da o verso un file utilizzando un buffer gestito
-internamente dal kernel. Descritta in questi termini \func{splice} sembra
-semplicemente un ``\textsl{dimezzamento}'' di \func{sendfile}.\footnote{nel
- senso che un trasferimento di dati fra due file con \func{sendfile} non
- sarebbe altro che la lettura degli stessi su un buffer seguita dalla
- relativa scrittura, cosa che in questo caso si dovrebbe eseguire con due
- chiamate a \func{splice}.} In realtà le due \textit{system call} sono
-profondamente diverse nel loro meccanismo di funzionamento;\footnote{questo
- fino al kernel 2.6.23, dove \func{sendfile} è stata reimplementata in
- termini di \func{splice}, pur mantenendo disponibile la stessa interfaccia
- verso l'user space.} \func{sendfile} infatti, come accennato, non necessita
-di avere a disposizione un buffer interno, perché esegue un trasferimento
-diretto di dati; questo la rende in generale più efficiente, ma anche limitata
-nelle sue applicazioni, dato che questo tipo di trasferimento è possibile solo
-in casi specifici.\footnote{e nel caso di Linux questi sono anche solo quelli
- in cui essa può essere effettivamente utilizzata.}
+l'allocazione di un buffer temporaneo per il loro trasferimento. Comunque a
+partire dal kernel 2.6.33 la restrizione su \param{out\_fd} è stata rimossa e
+questo può essere un file qualunque, rimane però quella di non poter usare un
+socket per \param{in\_fd}.
+
+A partire dal kernel 2.6.17 come alternativa a \func{sendfile} è disponibile
+la nuova \textit{system call} \func{splice}. Lo scopo di questa funzione è
+quello di fornire un meccanismo generico per il trasferimento di dati da o
+verso un file, utilizzando un buffer gestito internamente dal
+kernel. Descritta in questi termini \func{splice} sembra semplicemente un
+``\textsl{dimezzamento}'' di \func{sendfile}, nel senso che un trasferimento
+di dati fra due file con \func{sendfile} non sarebbe altro che la lettura
+degli stessi su un buffer seguita dalla relativa scrittura, cosa che in questo
+caso si dovrebbe eseguire con due chiamate a \func{splice}.
+
+In realtà le due \textit{system call} sono profondamente diverse nel loro
+meccanismo di funzionamento;\footnote{questo fino al kernel 2.6.23, dove
+ \func{sendfile} è stata reimplementata in termini di \func{splice}, pur
+ mantenendo disponibile la stessa interfaccia verso l'\textit{user space}.}
+\func{sendfile} infatti, come accennato, non necessita di avere a disposizione
+un buffer interno, perché esegue un trasferimento diretto di dati; questo la
+rende in generale più efficiente, ma anche limitata nelle sue applicazioni,
+dato che questo tipo di trasferimento è possibile solo in casi specifici che
+nel caso di Linux questi sono anche solo quelli in cui essa può essere
+effettivamente utilizzata.
Il concetto che sta dietro a \func{splice} invece è diverso,\footnote{in
realtà la proposta originale di Larry Mc Voy non differisce poi tanto negli
dallo stesso Linus Torvalds in \url{http://kerneltrap.org/node/6505}.} si
tratta semplicemente di una funzione che consente di fare in maniera del tutto
generica delle operazioni di trasferimento di dati fra un file e un buffer
-gestito interamente in kernel space. In questo caso il cuore della funzione (e
-delle affini \func{vmsplice} e \func{tee}, che tratteremo più avanti) è
-appunto l'uso di un buffer in kernel space, e questo è anche quello che ne ha
-semplificato l'adozione, perché l'infrastruttura per la gestione di un tale
-buffer è presente fin dagli albori di Unix per la realizzazione delle
-\textit{pipe} (vedi sez.~\ref{sec:ipc_unix}). Dal punto di vista concettuale
-allora \func{splice} non è altro che una diversa interfaccia (rispetto alle
-\textit{pipe}) con cui utilizzare in user space l'oggetto ``\textsl{buffer in
- kernel space}''.
+gestito interamente in \textit{kernel space}. In questo caso il cuore della
+funzione (e delle affini \func{vmsplice} e \func{tee}, che tratteremo più
+avanti) è appunto l'uso di un buffer in \textit{kernel space}, e questo è
+anche quello che ne ha semplificato l'adozione, perché l'infrastruttura per la
+gestione di un tale buffer è presente fin dagli albori di Unix per la
+realizzazione delle \textit{pipe} (vedi sez.~\ref{sec:ipc_unix}). Dal punto di
+vista concettuale allora \func{splice} non è altro che una diversa interfaccia
+(rispetto alle \textit{pipe}) con cui utilizzare in \textit{user space}
+l'oggetto ``\textsl{buffer in kernel space}''.
Così se per una \textit{pipe} o una \textit{fifo} il buffer viene utilizzato
come area di memoria (vedi fig.~\ref{fig:ipc_pipe_singular}) dove appoggiare i
dati che vengono trasferiti da un capo all'altro della stessa per creare un
meccanismo di comunicazione fra processi, nel caso di \func{splice} il buffer
viene usato o come fonte dei dati che saranno scritti su un file, o come
-destinazione dei dati che vengono letti da un file. La funzione \funcd{splice}
-fornisce quindi una interfaccia generica che consente di trasferire dati da un
-buffer ad un file o viceversa; il suo prototipo, accessibile solo dopo aver
-definito la macro \macro{\_GNU\_SOURCE},\footnote{si ricordi che questa
+destinazione dei dati che vengono letti da un file. La funzione fornisce
+quindi una interfaccia generica che consente di trasferire dati da un buffer
+ad un file o viceversa; il prototipo di \funcd{splice}, accessibile solo dopo
+aver definito la macro \macro{\_GNU\_SOURCE},\footnote{si ricordi che questa
funzione non è contemplata da nessuno standard, è presente solo su Linux, e
pertanto deve essere evitata se si vogliono scrivere programmi portabili.}
è il seguente:
-\begin{functions}
- \headdecl{fcntl.h}
- \funcdecl{long splice(int fd\_in, off\_t *off\_in, int fd\_out, off\_t
- *off\_out, size\_t len, unsigned int flags)}
-
- Trasferisce dati da un file verso una \textit{pipe} o viceversa.
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{long splice(int fd\_in, off\_t *off\_in, int fd\_out, off\_t
+ *off\_out, size\_t len, \\
+\phantom{long splice(}unsigned int flags)}
+\fdesc{Trasferisce dati da un file verso una \textit{pipe} o viceversa.}
+}
- \bodydesc{La funzione restituisce il numero di byte trasferiti in caso di
- successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
- dei valori:
- \begin{errlist}
+{La funzione ritorna il numero di byte trasferiti in caso di successo e $-1$
+ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
\item[\errcode{EBADF}] uno o entrambi fra \param{fd\_in} e \param{fd\_out}
non sono file descriptor validi o, rispettivamente, non sono stati
aperti in lettura o scrittura.
richiesta.
\item[\errcode{ESPIPE}] o \param{off\_in} o \param{off\_out} non sono
\val{NULL} ma il corrispondente file descriptor è una \textit{pipe}.
- \end{errlist}
- }
-\end{functions}
+ \end{errlist}
+}
+\end{funcproto}
+
La funzione esegue un trasferimento di \param{len} byte dal file descriptor
\param{fd\_in} al file descriptor \param{fd\_out}, uno dei quali deve essere
-una \textit{pipe}; l'altro file descriptor può essere
-qualunque.\footnote{questo significa che può essere, oltre che un file di
- dati, anche un altra \textit{pipe}, o un socket.} Come accennato una
-\textit{pipe} non è altro che un buffer in kernel space, per cui a seconda che
-essa sia usata per \param{fd\_in} o \param{fd\_out} si avrà rispettivamente la
-copia dei dati dal buffer al file o viceversa.
+una \textit{pipe}; l'altro file descriptor può essere qualunque, questo
+significa che può essere, oltre che un file di dati, anche un altra
+\textit{pipe}, o un socket. Come accennato una \textit{pipe} non è altro che
+un buffer in \textit{kernel space}, per cui a seconda che essa sia usata
+per \param{fd\_in} o \param{fd\_out} si avrà rispettivamente la copia dei dati
+dal buffer al file o viceversa.
In caso di successo la funzione ritorna il numero di byte trasferiti, che può
essere, come per le normali funzioni di lettura e scrittura su file, inferiore
\hline
\const{SPLICE\_F\_MOVE} & Suggerisce al kernel di spostare le pagine
di memoria contenenti i dati invece di
- copiarle;\footnotemark viene usato soltanto
- da \func{splice}.\\
+ copiarle: per una maggiore efficienza
+ \func{splice} usa quando possibile i
+ meccanismi della memoria virtuale per
+ eseguire i trasferimenti di dati. In maniera
+ analoga a \func{mmap}), qualora le pagine non
+ possano essere spostate dalla \textit{pipe} o
+ il buffer non corrisponda a pagine intere
+ esse saranno comunque copiate. Viene usato
+ soltanto da \func{splice}.\\
\const{SPLICE\_F\_NONBLOCK}& Richiede di operare in modalità non
bloccante; questo flag influisce solo sulle
operazioni che riguardano l'I/O da e verso la
ulteriori dati in una \func{splice}
successiva, questo è un suggerimento utile
che viene usato quando \param{fd\_out} è un
- socket.\footnotemark Attualmente viene usato
- solo da \func{splice}, potrà essere
+ socket. Questa opzione consente di utilizzare
+ delle opzioni di gestione dei socket che
+ permettono di ottimizzare le trasmissioni via
+ rete (si veda la descrizione di
+ \const{TCP\_CORK} in
+ sez.~\ref{sec:sock_tcp_udp_options} e quella
+ di \const{MSG\_MORE} in
+ sez.~\ref{sec:net_sendmsg}). Attualmente
+ viene usato solo da \func{splice}, potrà essere
implementato in futuro anche per
\func{vmsplice} e \func{tee}.\\
\const{SPLICE\_F\_GIFT} & Le pagine di memoria utente sono
- ``\textsl{donate}'' al kernel;\footnotemark
- se impostato una seguente \func{splice} che
+ ``\textsl{donate}'' al kernel; questo
+ significa che la cache delle pagine e i dati
+ su disco potranno differire, e che
+ l'applicazione non potrà modificare
+ quest'area di memoria.
+ Se impostato una seguente \func{splice} che
usa \const{SPLICE\_F\_MOVE} potrà spostare le
pagine con successo, altrimenti esse dovranno
essere copiate; per usare questa opzione i
\label{tab:splice_flag}
\end{table}
-\footnotetext[120]{per una maggiore efficienza \func{splice} usa quando
- possibile i meccanismi della memoria virtuale per eseguire i trasferimenti
- di dati (in maniera analoga a \func{mmap}), qualora le pagine non possano
- essere spostate dalla \textit{pipe} o il buffer non corrisponda a pagine
- intere esse saranno comunque copiate.}
-
-\footnotetext[121]{questa opzione consente di utilizzare delle opzioni di
- gestione dei socket che permettono di ottimizzare le trasmissioni via rete,
- si veda la descrizione di \const{TCP\_CORK} in
- sez.~\ref{sec:sock_tcp_udp_options} e quella di \const{MSG\_MORE} in
- sez.~\ref{sec:net_sendmsg}.}
-
-\footnotetext{questo significa che la cache delle pagine e i dati su disco
- potranno differire, e che l'applicazione non potrà modificare quest'area di
- memoria.}
Per capire meglio il funzionamento di \func{splice} vediamo un esempio con un
semplice programma che usa questa funzione per effettuare la copia di un file
-su un altro senza utilizzare buffer in user space. Il programma si chiama
-\texttt{splicecp.c} ed il codice completo è disponibile coi sorgenti allegati
-alla guida, il corpo principale del programma, che non contiene la sezione di
-gestione delle opzioni e le funzioni di ausilio è riportato in
-fig.~\ref{fig:splice_example}.
-
-Lo scopo del programma è quello di eseguire la copia dei con \func{splice},
-questo significa che si dovrà usare la funzione due volte, prima per leggere i
-dati e poi per scriverli, appoggiandosi ad un buffer in kernel space (vale a
-dire ad una \textit{pipe}); lo schema del flusso dei dati è illustrato in
-fig.~\ref{fig:splicecp_data_flux}.
+su un altro senza utilizzare buffer in \textit{user space}. Lo scopo del
+programma è quello di eseguire la copia dei dati con \func{splice}, questo
+significa che si dovrà usare la funzione due volte, prima per leggere i dati
+dal file di ingresso e poi per scriverli su quello di uscita, appoggiandosi ad
+una \textit{pipe}: lo schema del flusso dei dati è illustrato in
+fig.~\ref{fig:splicecp_data_flux}.
\begin{figure}[htb]
\centering
- \includegraphics[height=6cm]{img/splice_copy}
+ \includegraphics[height=3.5cm]{img/splice_copy}
\caption{Struttura del flusso di dati usato dal programma \texttt{splicecp}.}
\label{fig:splicecp_data_flux}
\end{figure}
-Una volta trattate le opzioni il programma verifica che restino
-(\texttt{\small 13-16}) i due argomenti che indicano il file sorgente ed il
-file destinazione. Il passo successivo è aprire il file sorgente
-(\texttt{\small 18-22}), quello di destinazione (\texttt{\small 23-27}) ed
-infine (\texttt{\small 28-31}) la \textit{pipe} che verrà usata come buffer.
+Il programma si chiama \texttt{splicecp.c} ed il codice completo è disponibile
+coi sorgenti allegati alla guida, il corpo principale del programma, che non
+contiene la sezione di gestione delle opzioni, le funzioni di ausilio, le
+aperture dei file di ingresso e di uscita passati come argomenti e quella
+della \textit{pipe} intermedia, è riportato in fig.~\ref{fig:splice_example}.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/splicecp.c}
\label{fig:splice_example}
\end{figure}
-Il ciclo principale (\texttt{\small 33-58}) inizia con la lettura dal file
-sorgente tramite la prima \func{splice} (\texttt{\small 34-35}), in questo
+Il ciclo principale (\texttt{\small 13-38}) inizia con la lettura dal file
+sorgente tramite la prima \func{splice} (\texttt{\small 14-15}), in questo
caso si è usato come primo argomento il file descriptor del file sorgente e
-come terzo quello del capo in scrittura della \textit{pipe} (il funzionamento
+come terzo quello del capo in scrittura della \textit{pipe}. Il funzionamento
delle \textit{pipe} e l'uso della coppia di file descriptor ad esse associati
è trattato in dettaglio in sez.~\ref{sec:ipc_unix}; non ne parleremo qui dato
che nell'ottica dell'uso di \func{splice} questa operazione corrisponde
-semplicemente al trasferimento dei dati dal file al buffer).
+semplicemente al trasferimento dei dati dal file al buffer in \textit{kernel
+ space}.
La lettura viene eseguita in blocchi pari alla dimensione specificata
dall'opzione \texttt{-s} (il default è 4096); essendo in questo caso
\func{splice} equivalente ad una \func{read} sul file, se ne controlla il
valore di uscita in \var{nread} che indica quanti byte sono stati letti, se
-detto valore è nullo (\texttt{\small 36}) questo significa che si è giunti
+detto valore è nullo (\texttt{\small 16}) questo significa che si è giunti
alla fine del file sorgente e pertanto l'operazione di copia è conclusa e si
può uscire dal ciclo arrivando alla conclusione del programma (\texttt{\small
- 59}). In caso di valore negativo (\texttt{\small 37-44}) c'è stato un
-errore ed allora si ripete la lettura (\texttt{\small 36}) se questo è dovuto
+ 59}). In caso di valore negativo (\texttt{\small 17-24}) c'è stato un
+errore ed allora si ripete la lettura (\texttt{\small 16}) se questo è dovuto
ad una interruzione, o altrimenti si esce con un messaggio di errore
-(\texttt{\small 41-43}).
+(\texttt{\small 21-23}).
Una volta completata con successo la lettura si avvia il ciclo di scrittura
-(\texttt{\small 45-57}); questo inizia (\texttt{\small 46-47}) con la
+(\texttt{\small 25-37}); questo inizia (\texttt{\small 26-27}) con la
seconda \func{splice} che cerca di scrivere gli \var{nread} byte letti, si
noti come in questo caso il primo argomento faccia di nuovo riferimento alla
\textit{pipe} (in questo caso si usa il capo in lettura, per i dettagli si
Di nuovo si controlla il numero di byte effettivamente scritti restituito in
\var{nwrite} e in caso di errore al solito si ripete la scrittura se questo è
dovuto a una interruzione o si esce con un messaggio negli altri casi
-(\texttt{\small 48-55}). Infine si chiude il ciclo di scrittura sottraendo
-(\texttt{\small 57}) il numero di byte scritti a quelli di cui è richiesta la
+(\texttt{\small 28-35}). Infine si chiude il ciclo di scrittura sottraendo
+(\texttt{\small 37}) il numero di byte scritti a quelli di cui è richiesta la
scrittura,\footnote{in questa parte del ciclo \var{nread}, il cui valore
iniziale è dato dai byte letti dalla precedente chiamata a \func{splice},
viene ad assumere il significato di byte da scrivere.} così che il ciclo di
Si noti come il programma sia concettualmente identico a quello che si sarebbe
scritto usando \func{read} al posto della prima \func{splice} e \func{write}
-al posto della seconda, utilizzando un buffer in user space per eseguire la
-copia dei dati, solo che in questo caso non è stato necessario allocare nessun
-buffer e non si è trasferito nessun dato in user space.
-
-Si noti anche come si sia usata la combinazione \texttt{SPLICE\_F\_MOVE |
- SPLICE\_F\_MORE } per l'argomento \param{flags} di \func{splice}, infatti
-anche se un valore nullo avrebbe dato gli stessi risultati, l'uso di questi
-flag, che si ricordi servono solo a dare suggerimenti al kernel, permette in
-genere di migliorare le prestazioni.
+al posto della seconda, utilizzando un buffer in \textit{user space} per
+eseguire la copia dei dati, solo che in questo caso non è stato necessario
+allocare nessun buffer e non si è trasferito nessun dato in \textit{user
+ space}. Si noti anche come si sia usata la combinazione
+\texttt{SPLICE\_F\_MOVE | SPLICE\_F\_MORE } per l'argomento \param{flags} di
+\func{splice}, infatti anche se un valore nullo avrebbe dato gli stessi
+risultati, l'uso di questi flag, che si ricordi servono solo a dare
+suggerimenti al kernel, permette in genere di migliorare le prestazioni.
Come accennato con l'introduzione di \func{splice} sono state realizzate anche
altre due \textit{system call}, \func{vmsplice} e \func{tee}, che utilizzano
la stessa infrastruttura e si basano sullo stesso concetto di manipolazione e
-trasferimento di dati attraverso un buffer in kernel space; benché queste non
-attengono strettamente ad operazioni di trasferimento dati fra file
+trasferimento di dati attraverso un buffer in \textit{kernel space}; benché
+queste non attengono strettamente ad operazioni di trasferimento dati fra file
descriptor, le tratteremo qui, essendo strettamente correlate fra loro.
La prima funzione, \funcd{vmsplice}, è la più simile a \func{splice} e come
indica il suo nome consente di trasferire i dati dalla memoria virtuale di un
processo (ad esempio per un file mappato in memoria) verso una \textit{pipe};
il suo prototipo è:
-\begin{functions}
- \headdecl{fcntl.h}
- \headdecl{sys/uio.h}
- \funcdecl{long vmsplice(int fd, const struct iovec *iov, unsigned long
- nr\_segs, unsigned int flags)}
-
- Trasferisce dati dalla memoria di un processo verso una \textit{pipe}.
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fhead{sys/uio.h}
+\fdecl{long vmsplice(int fd, const struct iovec *iov, unsigned long nr\_segs,\\
+\phantom{long vmsplice(}unsigned int flags)}
+\fdesc{Trasferisce dati dalla memoria di un processo verso una \textit{pipe}.}
+}
- \bodydesc{La funzione restituisce il numero di byte trasferiti in caso di
- successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
- dei valori:
- \begin{errlist}
+{La funzione ritorna il numero di byte trasferiti in caso di successo e $-1$
+ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
\item[\errcode{EBADF}] o \param{fd} non è un file descriptor valido o non
fa riferimento ad una \textit{pipe}.
\item[\errcode{EINVAL}] si è usato un valore nullo per \param{nr\_segs}
oppure si è usato \const{SPLICE\_F\_GIFT} ma la memoria non è allineata.
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
richiesta.
- \end{errlist}
- }
-\end{functions}
+ \end{errlist}
+}
+\end{funcproto}
La \textit{pipe} indicata da \param{fd} dovrà essere specificata tramite il
file descriptor corrispondente al suo capo aperto in scrittura (di nuovo si
eseguire una copia dei dati che contengono.
La seconda funzione aggiunta insieme a \func{splice} è \func{tee}, che deve il
-suo nome all'omonimo comando in user space, perché in analogia con questo
-permette di duplicare i dati in ingresso su una \textit{pipe} su un'altra
-\textit{pipe}. In sostanza, sempre nell'ottica della manipolazione dei dati su
-dei buffer in kernel space, la funzione consente di eseguire una copia del
-contenuto del buffer stesso. Il prototipo di \funcd{tee} è il seguente:
-\begin{functions}
- \headdecl{fcntl.h}
-
- \funcdecl{long tee(int fd\_in, int fd\_out, size\_t len, unsigned int
+suo nome all'omonimo comando in \textit{user space}, perché in analogia con
+questo permette di duplicare i dati in ingresso su una \textit{pipe} su
+un'altra \textit{pipe}. In sostanza, sempre nell'ottica della manipolazione
+dei dati su dei buffer in \textit{kernel space}, la funzione consente di
+eseguire una copia del contenuto del buffer stesso. Il prototipo di
+\funcd{tee} è il seguente:
+
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{long tee(int fd\_in, int fd\_out, size\_t len, unsigned int
flags)}
-
- Duplica \param{len} byte da una \textit{pipe} ad un'altra.
+\fdesc{Duplica i dati da una \textit{pipe} ad un'altra.}
+}
- \bodydesc{La funzione restituisce il numero di byte copiati in caso di
- successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
- dei valori:
- \begin{errlist}
+{La funzione ritorna restituisce il numero di byte copiati in caso di successo
+ e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
\item[\errcode{EINVAL}] o uno fra \param{fd\_in} e \param{fd\_out} non fa
riferimento ad una \textit{pipe} o entrambi fanno riferimento alla
stessa \textit{pipe}.
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
richiesta.
- \end{errlist}
- }
-\end{functions}
+ \end{errlist}
+}
+\end{funcproto}
La funzione copia \param{len} byte del contenuto di una \textit{pipe} su di
un'altra; \param{fd\_in} deve essere il capo in lettura della \textit{pipe}
La funzione restituisce il numero di byte copiati da una \textit{pipe}
all'altra (o $-1$ in caso di errore), un valore nullo indica che non ci sono
byte disponibili da copiare e che il capo in scrittura della \textit{pipe} è
-stato chiuso.\footnote{si tenga presente però che questo non avviene se si è
- impostato il flag \const{SPLICE\_F\_NONBLOCK}, in tal caso infatti si
- avrebbe un errore di \errcode{EAGAIN}.} Un esempio di realizzazione del
-comando \texttt{tee} usando questa funzione, ripreso da quello fornito nella
-pagina di manuale e dall'esempio allegato al patch originale, è riportato in
+stato chiuso; si tenga presente però che questo non avviene se si è impostato
+il flag \const{SPLICE\_F\_NONBLOCK}, in tal caso infatti si avrebbe un errore
+di \errcode{EAGAIN}. Un esempio di realizzazione del comando \texttt{tee}
+usando questa funzione, ripreso da quello fornito nella pagina di manuale e
+dall'esempio allegato al patch originale, è riportato in
fig.~\ref{fig:tee_example}. Il programma consente di copiare il contenuto
-dello standard input sullo standard output e su un file specificato come
-argomento, il codice completo si trova nel file \texttt{tee.c} dei sorgenti
-allegati alla guida.
+dello \textit{standard input} sullo \textit{standard output} e su un file
+specificato come argomento, il codice completo si trova nel file
+\texttt{tee.c} dei sorgenti allegati alla guida.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/tee.c}
\label{fig:tee_example}
\end{figure}
-La prima parte del programma (\texttt{\small 10-35}) si cura semplicemente di
-controllare (\texttt{\small 11-14}) che sia stato fornito almeno un argomento
-(il nome del file su cui scrivere), di aprirlo ({\small 15-19}) e che sia lo
-standard input (\texttt{\small 20-27}) che lo standard output (\texttt{\small
- 28-35}) corrispondano ad una \textit{pipe}.
+La prima parte del programma, che si è omessa per brevità, si cura
+semplicemente di controllare che sia stato fornito almeno un argomento (il
+nome del file su cui scrivere), di aprirlo e che sia lo standard input che lo
+standard output corrispondano ad una \textit{pipe}.
-Il ciclo principale (\texttt{\small 37-58}) inizia con la chiamata a
+Il ciclo principale (\texttt{\small 11-32}) inizia con la chiamata a
\func{tee} che duplica il contenuto dello standard input sullo standard output
-(\texttt{\small 39}), questa parte è del tutto analoga ad una lettura ed
+(\texttt{\small 13}), questa parte è del tutto analoga ad una lettura ed
infatti come nell'esempio di fig.~\ref{fig:splice_example} si controlla il
valore di ritorno della funzione in \var{len}; se questo è nullo significa che
-non ci sono più dati da leggere e si chiude il ciclo (\texttt{\small 40}), se
+non ci sono più dati da leggere e si chiude il ciclo (\texttt{\small 14}), se
è negativo c'è stato un errore, ed allora si ripete la chiamata se questo è
-dovuto ad una interruzione (\texttt{\small 42-44}) o si stampa un messaggio
-di errore e si esce negli altri casi (\texttt{\small 44-47}).
-
-Una volta completata la copia dei dati sullo standard output si possono
-estrarre dalla standard input e scrivere sul file, di nuovo su usa un ciclo di
-scrittura (\texttt{\small 50-58}) in cui si ripete una chiamata a
-\func{splice} (\texttt{\small 51}) fintanto che non si sono scritti tutti i
-\var{len} byte copiati in precedenza con \func{tee} (il funzionamento è
-identico all'analogo ciclo di scrittura del precedente esempio di
+dovuto ad una interruzione (\texttt{\small 15-48}) o si stampa un messaggio
+di errore e si esce negli altri casi (\texttt{\small 18-21}).
+
+Una volta completata la copia dei dati sullo \textit{standard output} si
+possono estrarre dallo \textit{standard input} e scrivere sul file, di nuovo
+su usa un ciclo di scrittura (\texttt{\small 24-31}) in cui si ripete una
+chiamata a \func{splice} (\texttt{\small 25}) fintanto che non si sono scritti
+tutti i \var{len} byte copiati in precedenza con \func{tee} (il funzionamento
+è identico all'analogo ciclo di scrittura del precedente esempio di
fig.~\ref{fig:splice_example}).
Infine una nota finale riguardo \func{splice}, \func{vmsplice} e \func{tee}:
\itindbeg{read-ahead}
Una prima funzione che può essere utilizzata per modificare la gestione
-ordinaria dell'I/O su un file è \funcd{readahead},\footnote{questa è una
- funzione specifica di Linux, introdotta con il kernel 2.4.13, e non deve
- essere usata se si vogliono scrivere programmi portabili.} che consente di
-richiedere una lettura anticipata del contenuto dello stesso in cache, così
-che le seguenti operazioni di lettura non debbano subire il ritardo dovuto
-all'accesso al disco; il suo prototipo è:
-\begin{functions}
- \headdecl{fcntl.h}
-
- \funcdecl{ssize\_t readahead(int fd, off64\_t *offset, size\_t count)}
-
- Esegue una lettura preventiva del contenuto di un file in cache.
+ordinaria dell'I/O su un file è \funcd{readahead} (questa è una funzione
+specifica di Linux, introdotta con il kernel 2.4.13, e non deve essere usata
+se si vogliono scrivere programmi portabili), che consente di richiedere una
+lettura anticipata del contenuto dello stesso in cache, così che le seguenti
+operazioni di lettura non debbano subire il ritardo dovuto all'accesso al
+disco; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{ssize\_t readahead(int fd, off64\_t *offset, size\_t count)}
+\fdesc{Esegue una lettura preventiva del contenuto di un file in cache.}
+}
- \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
- \begin{errlist}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
\item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
valido o non è aperto in lettura.
\item[\errcode{EINVAL}] l'argomento \param{fd} si riferisce ad un tipo di
file che non supporta l'operazione (come una \textit{pipe} o un socket).
- \end{errlist}
- }
-\end{functions}
+ \end{errlist}
+}
+\end{funcproto}
La funzione richiede che venga letto in anticipo il contenuto del file
\param{fd} a partire dalla posizione \param{offset} e per un ammontare di
in blocchi corrispondenti alle dimensioni delle pagine di memoria, ed i valori
di \param{offset} e \param{count} vengono arrotondati di conseguenza.
-La funzione estende quello che è un comportamento normale del kernel che
+La funzione estende quello che è un comportamento normale del kernel che,
quando si legge un file, aspettandosi che l'accesso prosegua, esegue sempre
una lettura preventiva di una certa quantità di dati; questo meccanismo di
lettura anticipata viene chiamato \textit{read-ahead}, da cui deriva il nome
\itindend{read-ahead}
Il concetto di \func{readahead} viene generalizzato nello standard
-POSIX.1-2001 dalla funzione \func{posix\_fadvise},\footnote{anche se
- l'argomento \param{len} è stato modificato da \type{size\_t} a \type{off\_t}
- nella revisione POSIX.1-2003 TC5.} che consente di ``\textsl{avvisare}'' il
+POSIX.1-2001 dalla funzione \func{posix\_fadvise} (anche se
+l'argomento \param{len} è stato modificato da \type{size\_t} a \type{off\_t}
+nella revisione POSIX.1-2003 TC1) che consente di ``\textsl{avvisare}'' il
kernel sulle modalità con cui si intende accedere nel futuro ad una certa
-porzione di un file,\footnote{la funzione però è stata introdotta su Linux
- solo a partire dal kernel 2.5.60.} così che esso possa provvedere le
-opportune ottimizzazioni; il prototipo di \funcd{posix\_fadvise}, che è
-disponibile soltanto se è stata definita la macro \macro{\_XOPEN\_SOURCE} ad
-valore di almeno 600, è:
-\begin{functions}
- \headdecl{fcntl.h}
-
- \funcdecl{int posix\_fadvise(int fd, off\_t offset, off\_t len, int advice)}
-
- Dichiara al kernel le future modalità di accesso ad un file.
+porzione di un file, così che esso possa provvedere le opportune
+ottimizzazioni; il prototipo di \funcd{posix\_fadvise}\footnote{la funzione è
+ stata introdotta su Linux solo a partire dal kernel 2.5.60, ed è disponibile
+ soltanto se è stata definita la macro \macro{\_XOPEN\_SOURCE} ad valore di
+ almeno \texttt{600} o la macro \macro{\_POSIX\_C\_SOURCE} ad valore di
+ almeno \texttt{200112L}.} è:
+
- \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
- \begin{errlist}
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{int posix\_fadvise(int fd, off\_t offset, off\_t len, int advice)}
+\fdesc{Dichiara al kernel le future modalità di accesso ad un file.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
\item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
valido.
\item[\errcode{EINVAL}] il valore di \param{advice} non è valido o
\param{fd} si riferisce ad un tipo di file che non supporta l'operazione
(come una \textit{pipe} o un socket).
- \item[\errcode{ESPIPE}] previsto dallo standard se \param{fd} è una \textit{pipe} o
- un socket (ma su Linux viene restituito \errcode{EINVAL}).
- \end{errlist}
- }
-\end{functions}
+ \item[\errcode{ESPIPE}] previsto dallo standard se \param{fd} è una
+ \textit{pipe} o un socket (ma su Linux viene restituito
+ \errcode{EINVAL}).
+ \end{errlist}
+}
+\end{funcproto}
La funzione dichiara al kernel le modalità con cui intende accedere alla
regione del file indicato da \param{fd} che inizia alla posizione
\param{offset} e si estende per \param{len} byte. Se per \param{len} si usa un
-valore nullo la regione coperta sarà da \param{offset} alla fine del
-file.\footnote{questo è vero solo per le versioni più recenti, fino al kernel
- 2.6.6 il valore nullo veniva interpretato letteralmente.} Le modalità sono
-indicate dall'argomento \param{advice} che è una maschera binaria dei valori
-illustrati in tab.~\ref{tab:posix_fadvise_flag}, che riprendono il significato
-degli analoghi già visti in sez.~\ref{sec:file_memory_map} per
+valore nullo la regione coperta sarà da \param{offset} alla fine del file, ma
+questo è vero solo per le versioni più recenti, fino al kernel 2.6.6 il valore
+nullo veniva interpretato letteralmente. Le modalità sono indicate
+dall'argomento \param{advice} che è una maschera binaria dei valori illustrati
+in tab.~\ref{tab:posix_fadvise_flag}, che riprendono il significato degli
+analoghi già visti in sez.~\ref{sec:file_memory_map} per
\func{madvise}.\footnote{dato che si tratta dello stesso tipo di funzionalità,
in questo caso applicata direttamente al sistema ai contenuti di un file
invece che alla sua mappatura in memoria.} Si tenga presente comunque che la
Questa è una indicazione utile che permette di alleggerire il carico sulla
cache, ed un programma può utilizzare periodicamente questa funzione per
liberare pagine di memoria da dati che non sono più utilizzati per far posto a
-nuovi dati utili.\footnote{la pagina di manuale riporta l'esempio dello
- streaming di file di grosse dimensioni, dove le pagine occupate dai dati già
- inviati possono essere tranquillamente scartate.}
+nuovi dati utili; la pagina di manuale riporta l'esempio dello streaming di
+file di grosse dimensioni, dove le pagine occupate dai dati già inviati
+possono essere tranquillamente scartate.
Sia \func{posix\_fadvise} che \func{readahead} attengono alla ottimizzazione
dell'accesso in lettura; lo standard POSIX.1-2001 prevede anche una funzione
-specifica per le operazioni di scrittura,
-\funcd{posix\_fallocate},\footnote{la funzione è stata introdotta a partire
- dalle glibc 2.1.94.} che consente di preallocare dello spazio disco per
-assicurarsi che una seguente scrittura non fallisca, il suo prototipo,
-anch'esso disponibile solo se si definisce la macro \macro{\_XOPEN\_SOURCE} ad
-almeno 600, è:
-\begin{functions}
- \headdecl{fcntl.h}
-
- \funcdecl{int posix\_fallocate(int fd, off\_t offset, off\_t len)}
-
- Richiede la allocazione di spazio disco per un file.
+specifica per le operazioni di scrittura, \funcd{posix\_fallocate} (la
+funzione è stata introdotta a partire dalle glibc 2.1.94), che consente di
+preallocare dello spazio disco per assicurarsi che una seguente scrittura non
+fallisca, il suo prototipo, anch'esso disponibile solo se si definisce la
+macro \macro{\_XOPEN\_SOURCE} ad almeno 600, è:
- \bodydesc{La funzione restituisce 0 in caso di successo e direttamente un
- codice di errore, in caso di fallimento, in questo caso \var{errno} non
- viene impostata, ma sarà restituito direttamente uno dei valori:
- \begin{errlist}
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{int posix\_fallocate(int fd, off\_t offset, off\_t len)}
+\fdesc{Richiede la allocazione di spazio disco per un file.}
+}
+
+{La funzione ritorna $0$ in caso di successo e direttamente un codice di
+ errore altrimenti, in tal caso \var{errno} non viene impostato, e si otterrà
+ direttamente uno dei valori:
+ \begin{errlist}
\item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
valido o non è aperto in scrittura.
\item[\errcode{EINVAL}] o \param{offset} o \param{len} sono minori di
l'operazione.
\item[\errcode{ESPIPE}] l'argomento \param{fd} è una \textit{pipe}.
\end{errlist}
- }
-\end{functions}
+}
+\end{funcproto}
La funzione assicura che venga allocato sufficiente spazio disco perché sia
possibile scrivere sul file indicato dall'argomento \param{fd} nella regione
Ci si può chiedere a cosa possa servire una funzione come
\func{posix\_fallocate} dato che è sempre possibile ottenere l'effetto voluto
-eseguendo esplicitamente sul file la scrittura\footnote{usando \funcd{pwrite}
- per evitare spostamenti della posizione corrente sul file.} di una serie di
-zeri per l'estensione di spazio necessaria qualora il \itindex{sparse~file}
-file debba essere esteso o abbia dei \index{file!\textit{hole}}
-buchi.\footnote{si ricordi che occorre scrivere per avere l'allocazione e che
- l'uso di \func{truncate} per estendere un file creerebbe soltanto uno
- \itindex{sparse~file} \textit{sparse file} (vedi sez.~\ref{sec:file_lseek})
- senza una effettiva allocazione dello spazio disco.} In realtà questa è la
-modalità con cui la funzione veniva realizzata nella prima versione fornita
-dalle \acr{glibc}, per cui la funzione costituiva in sostanza soltanto una
-standardizzazione delle modalità di esecuzione di questo tipo di allocazioni.
+eseguendo esplicitamente sul file la scrittura di una serie di zeri (usando
+\funcd{pwrite} per evitare spostamenti della posizione corrente sul file) per
+l'estensione di spazio necessaria qualora il file debba essere esteso o abbia
+dei buchi.\footnote{si ricordi che occorre scrivere per avere l'allocazione e
+ che l'uso di \func{truncate} per estendere un file creerebbe soltanto uno
+ \textit{sparse file} (vedi sez.~\ref{sec:file_lseek}) senza una effettiva
+ allocazione dello spazio disco.} In realtà questa è la modalità con cui la
+funzione veniva realizzata nella prima versione fornita dalle \acr{glibc}, per
+cui la funzione costituiva in sostanza soltanto una standardizzazione delle
+modalità di esecuzione di questo tipo di allocazioni.
Questo metodo, anche se funzionante, comporta però l'effettiva esecuzione una
scrittura su tutto lo spazio disco necessario, da fare al momento della
richiesta di allocazione, pagandone il conseguente prezzo in termini di
prestazioni; il tutto quando in realtà servirebbe solo poter riservare lo
spazio per poi andarci a scrivere, una sola volta, quando il contenuto finale
-diventa effettivamente disponibile.
-
-Per poter fare tutto questo è però necessario il supporto da parte del kernel,
-e questo è divenuto disponibile solo a partire dal kernel 2.6.23 in cui è
-stata introdotta la nuova \textit{system call} \func{fallocate},\footnote{non
- è detto che la funzione sia disponibile per tutti i filesystem, ad esempio
- per XFS il supporto è stato introdotto solo a partire dal kernel 2.6.25.}
-che consente di realizzare direttamente all'interno del kernel l'allocazione
-dello spazio disco così da poter realizzare una versione di
-\func{posix\_fallocate} con prestazioni molto più elevate.\footnote{nelle
- \acr{glibc} la nuova \textit{system call} viene sfruttata per la
- realizzazione di \func{posix\_fallocate} a partire dalla versione 2.10.}
+diventa effettivamente disponibile. Per poter fare tutto questo è però
+necessario il supporto da parte del kernel, e questo è divenuto disponibile
+solo a partire dal kernel 2.6.23 in cui è stata introdotta la nuova
+\textit{system call} \func{fallocate},\footnote{non è detto che la funzione
+ sia disponibile per tutti i filesystem, ad esempio per XFS il supporto è
+ stato introdotto solo a partire dal kernel 2.6.25.} che consente di
+realizzare direttamente all'interno del kernel l'allocazione dello spazio
+disco così da poter realizzare una versione di \func{posix\_fallocate} con
+prestazioni molto più elevate; nelle \acr{glibc} la nuova \textit{system call}
+viene sfruttata per la realizzazione di \func{posix\_fallocate} a partire
+dalla versione 2.10.
Trattandosi di una funzione di servizio, ed ovviamente disponibile
esclusivamente su Linux, inizialmente \funcd{fallocate} non era stata definita
sez.~\ref{sec:proc_syscall}, come \code{long fallocate(int fd, int mode,
loff\_t offset, loff\_t len)}.} ma a partire dalle \acr{glibc} 2.10 è
stato fornito un supporto esplicito; il suo prototipo è:
-\begin{functions}
- \headdecl{linux/fcntl.h}
- \funcdecl{int fallocate(int fd, int mode, off\_t offset, off\_t len)}
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{int fallocate(int fd, int mode, off\_t offset, off\_t len)}
+\fdesc{Prealloca dello spazio disco per un file.}
+}
- Prealloca dello spazio disco per un file.
-
- \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
- \begin{errlist}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
\item[\errcode{EBADF}] \param{fd} non fa riferimento ad un file descriptor
valido aperto in scrittura.
\item[\errcode{EFBIG}] la somma di \param{offset} e \param{len} eccede le
minore o uguale a zero.
\item[\errcode{ENODEV}] \param{fd} non fa riferimento ad un file ordinario
o a una directory.
- \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per l'operazione.
+ \item[\errcode{EPERM}] il file è immutabile o \textit{append-only} (vedi
+ sez.~\ref{sec:file_perm_overview}).
\item[\errcode{ENOSYS}] il filesystem contenente il file associato
a \param{fd} non supporta \func{fallocate}.
\item[\errcode{EOPNOTSUPP}] il filesystem contenente il file associato
a \param{fd} non supporta l'operazione \param{mode}.
- \end{errlist}
- ed inoltre \errval{EINTR}, \errval{EIO}.
-}
-\end{functions}
+ \end{errlist}
+ ed inoltre \errval{EINTR}, \errval{EIO} e \errval{ENOSPC} nel loro significato
+ generico.}
+\end{funcproto}
La funzione prende gli stessi argomenti di \func{posix\_fallocate} con lo
stesso significato, a cui si aggiunge l'argomento \param{mode} che indica le
-modalità di allocazione; al momento quest'ultimo può soltanto essere nullo o
-assumere il valore \const{FALLOC\_FL\_KEEP\_SIZE} che richiede che la
-dimensione del file\footnote{quella ottenuta nel campo \var{st\_size} di una
- struttura \struct{stat} dopo una chiamata a \texttt{fstat}.} non venga
-modificata anche quando la somma di \param{offset} e \param{len} eccede la
-dimensione corrente.
-
-Se \param{mode} è nullo invece la dimensione totale del file in caso di
-estensione dello stesso viene aggiornata, come richiesto per
-\func{posix\_fallocate}, ed invocata in questo modo si può considerare
-\func{fallocate} come l'implementazione ottimale di \func{posix\_fallocate} a
-livello di kernel.
+modalità di allocazione; se questo è nullo il comportamento è identico a
+quello di \func{posix\_fallocate} e si può considerare \func{fallocate} come
+l'implementazione ottimale della stessa a livello di kernel.
+
+Inizialmente l'unico altro valore possibile per \param{mode} era
+\const{FALLOC\_FL\_KEEP\_SIZE} che richiede che la dimensione del file (quella
+ottenuta nel campo \var{st\_size} di una struttura \struct{stat} dopo una
+chiamata a \texttt{fstat}) non venga modificata anche quando la somma
+di \param{offset} e \param{len} eccede la dimensione corrente, che serve
+quando si deve comunque preallocare dello spazio per scritture in append. In
+seguito sono stati introdotti altri valori, riassunti in
+tab.\ref{tab:fallocate_mode}, per compiere altre operazioni relative alla
+allocazione dello spazio disco dei file.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{10cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{FALLOC\_FL\_INSERT} & .\\
+ \const{FALLOC\_FL\_COLLAPSE\_RANGE}& .\\
+ \const{FALLOC\_FL\_KEEP\_SIZE} & Mantiene invariata la dimensione del
+ file, pur allocando lo spazio disco anche
+ oltre la dimensione corrente del file.\\
+ \const{FALLOC\_FL\_PUNCH\_HOLE}& Crea un \textsl{buco} nel file (vedi
+ sez.~\ref{sec:file_lseek}) rendendolo una
+ \textit{sparse file} (dal kernel
+ 2.6.38).\\
+ \const{FALLOC\_FL\_ZERO\_RANGE}& .\\
+ \hline
+ \end{tabular}
+ \caption{Valori delle costanti usabili per l'argomento \param{mode} di
+ \func{fallocate}.}
+ \label{tab:fallocate_mode}
+\end{table}
+
+In particolare con \const{FALLOC\_FL\_PUNCH\_HOLE} è possibile scartare il
+contenuto della sezione di file indicata da \param{offser} e \param{len},
+creando un \textsl{buco} (si ricordi quanto detto in
+sez.~\ref{sec:file_lseek}); i blocchi del file interamente contenuti
+nell'intervallo verranno disallocati, la parte di intervallo contenuta
+parzialmente in altri blocchi verrà riempita con zeri e la lettura dal file
+restituirà degli zeri per tutto l'intervallo indicato. In sostanza si rende il
+file uno \textit{sparse file} a posteriori.
% vedi http://lwn.net/Articles/226710/ e http://lwn.net/Articles/240571/
% http://kernelnewbies.org/Linux_2_6_23
% nel kernel 3.15 (sul secondo vedi http://lwn.net/Articles/589260/), vedi
% anche http://lwn.net/Articles/629965/
+% TODO aggiungere FALLOC_FL_INSERT vedi http://lwn.net/Articles/629965/
+
+
% TODO non so dove trattarli, ma dal 2.6.39 ci sono i file handle, vedi
% http://lwn.net/Articles/432757/
% LocalWords: clockid CLOCK MONOTONIC REALTIME itimerspec interval Resource
% LocalWords: ABSTIME gettime temporarily unavailable SIGINT SIGQUIT SIGTERM
% LocalWords: sigfd fifofd break siginf names starting echo Message from Got
-% LocalWords: message kill received means exit
+% LocalWords: message kill received means exit TLOCK ULOCK EPOLLWAKEUP
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+
projects / gapil.git / blobdiff