X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=a0c5f05952542ec2a59cb6906e3d02f3cfaaf658;hp=f805181d3a5c0768cd326b25dd987d63bd19cb5f;hb=91a32c34eddac8bd0e550468c771d869beccdbc5;hpb=017baa9ca8e1da7c8951d269125cfab35c427e08 diff --git a/fileadv.tex b/fileadv.tex index f805181..a0c5f05 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -91,7 +91,7 @@ con la funzione \func{select}, il cui prototipo La funzione mette il processo in stato di \textit{sleep} (vedi \tabref{tab:proc_proc_states}) fintanto che almeno uno dei file descriptor -degli insiemo specificati (\param{readfds}, \param{writefds} e +degli insiemi specificati (\param{readfds}, \param{writefds} e \param{exceptfds}), non diventa attivo, per un tempo massimo specificato da \param{timeout}. @@ -168,7 +168,7 @@ Come accennato l'interfaccia di \func{select} System V ha introdotto una sua interfaccia per gestire l'\textit{I/O multiplexing}, basata sulla funzione \func{poll},\footnote{la funzione è prevista dallo standard XPG4, ed è stata introdotta in Linux come system - call a partire dal kernel 2.1.23 e dalle libc 5.4.28.} il cui prototipo è: + call a partire dal kernel 2.1.23 e dalle \acr{libc} 5.4.28.} il cui prototipo è: \begin{prototype}{sys/poll.h} {int poll(struct pollfd *ufds, unsigned int nfds, int timeout)} @@ -191,7 +191,7 @@ specificati attraverso un vettore di puntatori a strutture di tipo \type{pollfd}, la cui definizione è riportata in \figref{fig:file_pollfd}. Come \func{select} anche \func{poll} permette di interrompere l'attesa dopo un certo tempo, che va specificato attraverso \param{timeout} in numero di -millesecondi (un valore negativo indica un'attesa indefinita). +millisecondi (un valore negativo indica un'attesa indefinita). \begin{figure}[!htb] \footnotesize \centering @@ -230,7 +230,7 @@ vengono utilizzati solo per \var{revents} come valori in uscita). \macro{POLLOUT} & 0x004 & È possibile la scrittura immediata.\\ \hline \macro{POLLERR} & 0x008 & C'è una condizione di errore.\\ - \macro{POLLHUP} & 0x010 & Si è vericato un hung-up.\\ + \macro{POLLHUP} & 0x010 & Si è verificato un hung-up.\\ \macro{POLLNVAL} & 0x020 & Il file descriptor non è aperto.\\ \hline \macro{POLLRDNORM}& 0x040 & Sono disponibili in lettura dati normali.\\ @@ -262,7 +262,7 @@ ad esso relative vengano dichiarate nell'header \file{sys/select.h}, che sostituisce i precedenti, ed aggiunge a \func{select} una nuova funzione \func{pselect},\footnote{il supporto per lo standard POSIX 1003.1-2001, ed l'header \file{sys/select.h}, compaiono in Linux a partire dalle \acr{glibc} - 2.0. Le \acr{libc4} e \acr{libc5} non contengono questo header, le + 2.1. Le \acr{libc4} e \acr{libc5} non contengono questo header, le \acr{glibc} 2.0 contengono una definizione sbagliata di \func{psignal}, senza l'argomento \param{sigmask}, la definizione corretta è presente dalle \acr{glibc} 2.1-2.2.1 se si è definito \macro{\_GNU\_SOURCE} e nelle @@ -337,9 +337,9 @@ modalit In questo modo si può evitare l'uso delle funzioni \func{poll} o \func{select} che, quando vengono usate con un numero molto grande di file descriptor, non hanno buone prestazioni. In tal caso infatti la maggior parte del loro tempo -di esecuzione è impegato per eseguire uno scan su tutti i file descriptor -tenuti sotto controllo per determinare quali sono quelli (in genere un piccola -percentuale) che sono diventati attivi. +di esecuzione è impegnato ad eseguire una scansione su tutti i file descriptor +tenuti sotto controllo per determinare quali di essi (in genere una piccola +percentuale) sono diventati attivi. Tuttavia con l'implementazione classica dei segnali questa modalità di I/O presenta notevoli problemi, dato che non è possibile determinare, quando sono @@ -354,7 +354,7 @@ Per far questo per (vedi \secref{sec:sig_real_time}) settando esplicitamente con il comando \macro{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di I/O asincrono (il segnale di default è \macro{SIGIO}). In questo caso il -manipolatorem tutte le volte che riceverà \macro{SI\_SIGIO} come valore del +manipolatore tutte le volte che riceverà \macro{SI\_SIGIO} come valore del campo \var{si\_code}\footnote{il valore resta \macro{SI\_SIGIO} qualunque sia il segnale che si è associato all'I/O asincrono, ed indica appunto che il segnale è stato generato a causa di attività nell'I/O asincrono.} di @@ -366,7 +366,12 @@ una coda di consegna ogni segnale sar inoltre sarà possibile stabilire delle priorità nella risposta a seconda del segnale usato. In questo modo si può identificare immediatamente un file su cui l'accesso è diventato possibile evitando completamente l'uso di funzioni -come \func{poll} e \func{select}. +come \func{poll} e \func{select}, almeno fintanto che non si satura la coda; +si eccedono le dimensioni di quest'ultima; in tal caso infatti il kernel, non +potendo più assicurare il comportamento corretto per un segnale real-time, +invierà al suo posto un \var{SIGIO}, su cui si accumuleranno tutti i segnali +in eccesso, e si dovrà determinare al solito modo quali sono i file diventati +attivi. Benché la modalità di apertura asincrona di un file possa risultare utile in varie occasioni (in particolar modo con i socket e gli altri file per i quali @@ -385,8 +390,354 @@ di thread. Al momento\footnote{fino ai kernel della serie 2.4.x, nella serie asincrono.} esiste una sola versione stabile di questa interfaccia, quella delle \acr{glibc}, che è realizzata completamente in user space. Esistono comunque vari progetti sperimentali (come il KAIO della SGI, o i patch di -Benjamin La Haise) che prevedono una interfaccia che utilizza un supporto -diretto da parte del kernel. +Benjamin La Haise) che prevedono un supporto diretto da parte del kernel. + +Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate +attraverso l'uso di una apposita struttura \type{aiocb} (il cui nome sta per +\textit{asyncronous I/O control block}), che viene passata come argomento a +tutte le funzioni dell'interfaccia. La sua definizione, come effettuata in +\file{aio.h}, è riportata in \figref{fig:file_aiocb}. Nello steso file è +definita la macro \macro{\_POSIX\_ASYNCHRONOUS\_IO}, che dichiara la +disponibilità di questa funzionalità. + +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{15cm} + \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{} +struct aiocb +{ + int aio_fildes; /* File descriptor. */ + off_t aio_offset; /* File offset */ + int aio_lio_opcode; /* Operation to be performed. */ + int aio_reqprio; /* Request priority offset. */ + volatile void *aio_buf; /* Location of buffer. */ + size_t aio_nbytes; /* Length of transfer. */ + struct sigevent aio_sigevent; /* Signal number and value. */ +}; + \end{lstlisting} + \end{minipage} + \normalsize + \caption{La struttura \type{aiocb}, usata per il controllo dell'I/O + asincrono.} + \label{fig:file_aiocb} +\end{figure} + +Le operazioni di I/O asincrono possono essere effettuate solo su un file già +aperto, il cui file descriptor deve essere specificato tramite il campo +\var{aio\_fildes}; il file deve inoltre supportare la funzione \func{lseek}, +pertanto terminali e pipe sono esclusi. Non c'è limite al numero di operazioni +contemporanee effettuabili su un singolo file. + +Dato che più operazioni possono essere eseguita in maniera asincrona, il +concetto di posizione corrente sul file viene a mancare; pertanto ciascuna +operazione deve sempre specificare nel campo \var{aio\_offset} la posizione +sul file da cui i dati saranno letti o scritti. Nel campo \var{aio\_buf} poi +andrà specificato l'indirizzo del buffer usato per l'I/O, ed in +\var{aio\_nbytes} la lunghezza del trasferimento. + +Il campo \var{aio\_reqprio} permette di settare la priorità delle operazioni +di I/O.\footnote{in generale perché ciò sia possibile occorre che la + piattaforma supporti questa caratteristica, questo viene indicato definendo + le macro \macro{\_POSIX\_PRIORITIZED\_IO}, e + \macro{\_POSIX\_PRIORITY\_SCHEDULING}.} La priorità viene settata a partire +da quella del processo chiamante (vedi \secref{sec:proc_priority}), cui viene +sottratto il valore di questo campo. + +Il campo \var{aio\_lio\_opcode} è usato dalla funzione \func{lio\_listio}, che +permette di far partire una serie di operazioni in contemporanea su una lista +di file. Tramite questo campo si specifica quale è la natura di ciascuna di +esse. + +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{15cm} + \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{} +struct sigevent +{ + sigval_t sigev_value; + int sigev_signo; + int sigev_notify; + sigev_notify_function; + sigev_notify_attributes; +}; + \end{lstlisting} + \end{minipage} + \normalsize + \caption{La struttura \type{sigevent}, usata per specificare le modailtà di + notifica degli eventi relativi alle operazioni di I/O asincrono.} + \label{fig:file_sigevent} +\end{figure} + +Infine il campo \var{aio\_sigevent} è una struttura di tipo \type{sigevent} +che serve a specificare il modo in cui si vuole che venga effettuata la +notifica del completamento delle operazioni richieste. La struttura è +riportata in \secref{fig:file_sigevent}; il campo \var{sigev\_notify} è quello +che indica le modalità della notifica, esso può assumere i tre valori: +\begin{basedescript}{\desclabelwidth{3.0cm}} +\item[\macro{SIGEV\_NONE}] Non viene inviata nessuna notifica. +\item[\macro{SIGEV\_SIGNAL}] La notifica viene effettuata inviando al processo + chiamante il segnale specificato nel campo \var{sigev\_signo}, se il + manipolatore è installato con \macro{SA\_SIGINFO}, il gli verrà restituito + il valore di \var{sigev\_value} in come valore del campo \var{si\_value} per + \type{siginfo\_t}. +\item[\macro{SIGEV\_THREAD}] La notifica viene effettuata creando un nuovo + thread che esegue la funzione specificata da \var{sigev\_notify\_function}, + con gli attributi specificati da \var{sigev\_notify\_attribute}. +\end{basedescript} + +Le due funzioni base dell'interfaccia POSIX.1b per l'I/O asincrono sono +\func{aio\_read} e \func{aio\_write}. Esse servono a richiedere una lettura +od una scrittura asincrona di dati usando la struttura \type{aiocb} appena +descritta; i rispettivi prototipi sono: +\begin{functions} + \headdecl{aio.h} + + \funcdecl{int aio\_read(struct aiocb *aiocbp)} + Richiede una lettura asincrona secondo quanto specificato con \param{aiocbp}. + + \funcdecl{int aio\_write(struct aiocb *aiocbp)} + Richiede una scrittura asincrona secondo quanto specificato con + \param{aiocbp}. + + \bodydesc{Le funzioni restituiscono 0 in caso di successo, e -1 in caso di + errore, nel qual caso \var{errno} viene settata ai valori: + \begin{errlist} + \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato. + \item[\macro{ENOSYS}] La funzione non è implementata. + \item[\macro{EINVAL}] Si è specificato un valore non valido per i campi + \var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}. + \item[\macro{EAGAIN}] La coda delle richieste è momentaneamente piena. + \end{errlist} +} +\end{functions} + +Entrambe le funzioni ritornano immediatamente dopo aver messo in coda la +richiesta, o in caso di errore. Non è detto che gli errori \macro{EBADF} ed +\macro{EINVAL} siano rilevati immediatamente al momento della chiamata, +potrebbero anche emergere nelle fasi successive delle operazioni. Lettura e +scrittura avvengono alla posizione indicata da \var{aio\_offset}, a meno che +il file non sia stato aperto in \textit{append mode} (vedi +\secref{sec:file_open}), nel qual caso le scritture vengono effettuate +comunque alla fine de file, nell'ordine delle chiamate a \func{aio\_write}. + +Si tenga inoltre presente che deallocare la memoria indirizzata da +\param{aiocbp} o modificarne i valori prima della conclusione di una +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 occorre evitare di usare per \param{aiocbp} +variabili automatiche, effettuando le chiamate all'interno di una subroutine, +e che non si deve riutilizzare la stessa struttura per un'ulteriore operazione +fintanto che la precedente non si sia ultimata. In generale per ogni +operazione di I/O asincrono si deve utilizzare una ed una sola struttura +\type{aiocb}. + +Si ricordi che, operando in modalità asincrona, il successo di queste funzioni +non implica che le operazioni richieste siano state effettivamente eseguite in +maniera corretta. Per verificare l'esito delle operazioni l'interfaccia +prevede altre due funzioni, che permettono di controllare lo stato di +esecuzione. La prima è \func{aio\_error}, che serve a determinare un eventuale +stato di errore; il suo prototipo è: +\begin{prototype}{aio.h} + {int aio\_error(const struct aiocb *aiocbp)} + + Determina lo stato di errore delle operazioni di I/O associate a + \param{aiocbp}. + + \bodydesc{La funzione restituisce 0 se le operazioni si sono concluse con + successo, altrimenti restituisce il codice di errore.} +% }, che viene salvato +% anche in \var{errno}, i valori possibili sono: +% \begin{errlist} +% \item[\macro{ENOSYS}] La funzione non è implementata. +% \item[\macro{EINPROGRESS}] L'operazione è ancora in corso. +% \item[\macro{EINVAL}] Si è specificato un valore non valido per i campi +% \var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}. +% \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato. +% \end{errlist} +% più tutti quelli possibili per le sottostanti operazioni, .} +\end{prototype} + +Se l'operazione non si è ancora completata viene restituito l'errore di +\macro{EINPROGRESS}. La funzione ritorna zero quando l'operazione si è +conclusa con successo, altrimenti restituisce il codice di errore, ed esegue +il settaggio di \var{errno}. In caso caso di errore esso può essere sia uno +dei precedentemente specificati \macro{EINVAL} ed \macro{EBADF}, dovuti ad un +valore errato per \param{aiocbp} che uno dei possibili errori dovuti alle +chiamate al sistema sottostanti l'esecuzione dell'operazione di I/O richiesta, +relativi alle funzioni \func{read}, \func{write} e \func{fsync}. + + +Una volta che si sia certi che le operazioni si siano concluse (cioè dopo che +una chiamata ad \func{aio\_error} non ha restituito \macro{EINPROGRESS}, si +può usare la seconda funzione dell'interfaccia, \func{aio\_return}, per +verificare il completamento delle operazioni di I/O asincrono, il cui +prototipo è: +\begin{prototype}{aio.h} +{ssize\_t aio\_return(const struct aiocb *aiocbp)} + +Recupera il valore dello stato di ritorno delle operazioni di I/O associate a +\param{aiocbp}. + +\bodydesc{La funzione restituisce lo stato di uscita dell'operazione + eseguita.} +\end{prototype} + +La funzione deve essere chiamata una sola volte per ciascuna operazione +asincrona, essa infatti fa sì che il sistema rilasci le risorse associate a +ciascuna operazione. Per questo motivo occorre chiamare la funzione solo dopo +che l'operazione cui \param{aiocbp} fa riferimento si è completata. + +La funzione restituisce il valore di ritorno relativa all'operazione eseguita, +così come ricavato dalla sottostante system call (il numero di byte letti, +scritti o il valore di ritorno di \func{fsync}). É importante chiamare sempre +questa funzione, altrimenti le risorse disponibili per le operazioni di I/O +asincrono non verrebbero liberate, rischiando di arrivare ad un loro +esaurimento. + +Oltre alle operazioni di lettura e scrittura l'interfaccia POSIX.1b mette a +disposizione un'altra operazione, quella di sincronizzazione delll'I/O, essa è +compiuta dalla funzione \func{aio\_fsync}, che ha lo stesso effetto della +analoga \func{fsync}, ma viene esguita in maniera asincrona; il suo prototipo +è: +\begin{prototype}{aio.h} +{ssize\_t aio\_return(int op, struct aiocb *aiocbp)} + +Richiede la sincronizzazione dei dati per il file indicato da \param{aiocbp}. + +\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di + errore, che può essere, con le stesse modalità di \func{aio\_read}, + \macro{EAGAIN}, \macro{EBADF} o \macro{EINVAL}.} +\end{prototype} + +La funzione richiede la sincronizzazione delle operazioni di I/O, essendo la +richiesta asincrona, ritornando immediatamente. L'esecuzione effettiva della +sincronizzazione dovrà essere verificata con \func{aio\_error} e +\func{aio\_return} come per le operazioni di lettura e scrittura. L'argomento +\param{op} permette di indicare la modalità di esecuzione, se si specifica il +valore \macro{O\_DSYNC} le operazioni saranno completate con una chiamata a +\func{fdatasync}, se si specifica \macro{O\_SYNC} con una chiamata a +\func{fsync} (vedi \secref{sec:file_sync}). + +Il successo della chiamata assicura la sincronizzazione delle operazioni fino +allora richieste, niente è garantito riguardo la sincronizzazione dei dati +relativi ad eventuali operazioni richieste successivamente. Se si è +specificato un meccanismo di notifica questo sarà innescato una volta che le +operazioni di sincronizzazione dei dati saranno completate. + +In alcuni casi può essere necessario interrompere le operazioni (in genere +quando viene richiesta un'uscita immediata dal programam), per questo lo +standard POSIX.1b prevede una funzioni apposita, \func{aio\_cancel}, che +permette di cancellare una operazione richiesta in precedenza; il suo +prototipo è: +\begin{prototype}{aio.h} +{int aio\_cancel(int fildes, struct aiocb *aiocbp)} + +Richiede la cancellazione delle operazioni sul file \param{fildes} specificate +da \param{aiocbp}. + +\bodydesc{La funzione restituisce il risultato dell'operazione con un codice + di positivo, e -1 in caso di errore, che avviene qualora si sia specificato + un valore non valido di \param{fildes}, setta \var{errno} al valore + \macro{EBADF}.} +\end{prototype} + +La funzione permette di cancellare una operazione specifica sul file +\param{fildes}, o tutte le operazioni pendenti, specificando \macro{NULL} come +valore di \param{aiocbp}. Quando una operazione viene cancellata +\func{aio\_error} riporterà \macro{ECANCELED} come codice di errore, ed il suo +codice di ritorno sarà -1, inoltre il meccanismo di notifica non verrà +invocato. + +I possibili valori di ritorno di \func{aio\_cancel} sono tre: +\macro{AIO\_ALLDONE} indica che le operazioni di cui si è richiesta la +cancellazione sono state già completate, \macro{AIO\_CANCELED} indica che +tutte le operazioni richieste sono state cancellate, e +\macro{AIO\_NOTCANCELED} che alcune delle operazioni erano in corso e non sono +state cancellate. + +In quest'ultimo caso occorre chiamare \func{aio\_error} per determinare quali +sono le operazioni cancellate. Le operazioni che non sono state cancellate +proseguono il loro corso normale, compreso quanto relativo al meccanismo di +notifica del loro avvenuto completamento. + +Benché l'I/O asincrono preveda un meccanismo di notifica, che permette di +bloccare un processo in maniera relativamente semplice fino al completamento +di una determinata operazione, lo standard fornisce anche una apposita +funzione, \func{aio\_suspend}, che permette di sospendere l'esecuzione di un +processo fino al completamento di una specifica operazione; il suo prototipo +è: +\begin{prototype}{aio.h} +{int aio\_suspend(const struct aiocb * const list[], int nent, const struct + timespec *timeout)} + + Attende, per un massimo di \param{timeout}, il completamento di una delle + operazioni specificate da \param{list}. + + \bodydesc{La funzione restituisce 0 se una (o più) operazioni sono state + completate, e -1 in caso di errorem nel qual caso \var{errno} viene + settata ai valori: + \begin{errlist} + \item[\macro{EAGAIN}] Nessuna operazione è stata completata entro + \param{timeout}. + \item[\macro{ENOSYS}] La funzione non è implementata. + \item[\macro{EINTR}] La funzione è stata interrotta da un segnale. + \end{errlist} + } +\end{prototype} + +La funzione permette di bloccare il processo chiamante fintanto che almeno una +delle \param{nent} operazioni specificate nella lista \param{list} è +completata, per un tempo massimo specificato da \param{timout}, o fintanto che +non arrivi un segnale.\footnote{si tenga conto che questo segnale può anche + essere quello utilizzato come meccanismo di notifica.} La lista deve essere +inizializzata con delle strutture \var{aiocb} relative ad operazioni +effettivamente richieste, ma può contenere puntatori nulli, che saranno +ignorati. In caso si siano specificati valori non validi l'effetto è +indefinito. Un valore \macro{NULL} per \param{timout} comporta una attesa +infinita. + +Lo standard infine ha previsto pure una funzione, \func{lio\_listio}, che +permette di effettuare la richiesta di una intera lista di operazioni di +lettura o scrittura; il suo prototipo è: +\begin{prototype}{aio.h} + {int lio\_listio(int mode, struct aiocb * const list[], int nent, struct + sigevent *sig)} + + Richiede l'esecuzione delle operazioni di I/O elencata da \param{list}, + secondo la modalità \param{mode}. + + \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di + errorem nel qual caso \var{errno} viene settata ai valori: + \begin{errlist} + \item[\macro{EAGAIN}] Nessuna operazione è stata completata entro + \param{timeout}. + \item[\macro{ENOSYS}] La funzione non è implementata. + \item[\macro{EINTR}] La funzione è stata interrotta da un segnale. + \end{errlist} + } +\end{prototype} + +La funzione esegue la richiesta delle \param{nent} operazioni indicate dalla +lista \param{list}; questa deve contenere gli indirizzi di altrettanti control +block, opportunamente inizializzati; in particolare nel caso dovrà essere +specificato il tipo di operazione tramite il campo \var{aio\_lio\_opcode}, che +può prendere i tre valori: +\begin{description*} +\item[\macro{LIO\_READ}] richiede una operazione di lettura. +\item[\macro{LIO\_WRITE}] richiede una operazione di scrittura. +\item[\macro{LIO\_NOP}] non effettua nessuna operazione. +\end{description*} +l'ultimo viene usato quando si ha a che fare con un vettore di dimensione +fissa, per poter specificare solo alcune operazioni, o quando si è dovuto +cancellare delle operazioni e si deve ripetere la richiesta per quelle non +completate. + +L'argomento \param{mode} permette di stabilire il comportamento della +funzione, se viene specificato il valore \macro{LIO\_WAIT} la funzione si +blocca fino al completamento di tutte le operazioni richieste; se invece si +spercifica \macro{LIO\_NOWAIT} la funzione ritorna immediatamente dopo aver +messo in coda tutte le richieste. In questo caso il chiamante può richiedere +una notifica del completamento di tutte le richieste settando \param{sig}. @@ -396,7 +747,7 @@ diretto da parte del kernel. Un caso abbastanza comune è quello in cui ci si trova a dover affrontare una serie multipla di operazioni di I/O, come una serie di letture o scritture di -vari buffer. In questo caso +vari buffer. In questo caso