X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=56b24be494b38014af2817cacdffab6bf17b3dcf;hp=5b0816293e0a5379d8cd3b8c6bb67458887cc3b1;hb=1e09a8256d97540694702ac3952f36281542bc60;hpb=bf78d63598adf72d71aeea3c32277dd63484bb02 diff --git a/fileadv.tex b/fileadv.tex index 5b08162..56b24be 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 @@ -335,44 +335,53 @@ modalit \func{fcntl}, quale processo (o gruppo di processi) riceverà il segnale. In questo modo si può evitare l'uso delle funzioni \func{poll} o \func{select} -che normalmente quando vengono usate con un grande numero di file descriptor, -non hanno buone prestazioni, in quanto passano maggior parte del tempo ad -eseguire uno scan per determinare quali sono quelli (in genere un piccola -percentuale) che sono diventati attivi. - -Uno dei problemi che si presenta con l'implementazione usuale di questa -modalità di I/O è che essa può essere usata in maniera immediata aprendo in -modalità asincrona un solo file per processo, altrimenti ad ogni segnale si -dovrebbe provvedere ad effettuare un controllo, utilizzando di nuovo -\func{poll} o \func{select} su tutti i file tenuti in modalità asincrona per -distinguere quelli cui è dovuta l'emissione del segnale. - -Linux però supporta una estensione che permette di evitare tutto questo -facendo ricorso alle informazioni aggiuntive restituite attraverso la -struttura \type{siginfo\_t} quando il manipolatore del segnale viene -installato come \macro{SA\_SIGINFO} (si riveda quanto illustrato in -\secref{sec:sig_sigaction}). - -Per attivare questa caratteristica occorre utilizzare le funzionalità dei -segnali real-time (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 (di norma viene usato \macro{SIGIO}). In questo caso -il manipolatore tutte le volte che riceverà \macro{SI\_SIGIO} come valore del +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 è 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 +più di uno, qual'è il file descriptor responsabile dell'emissione del segnale. +Linux però supporta le estensioni POSIX.1b dei segnali che permettono di +superare il problema facendo ricorso alle informazioni aggiuntive restituite +attraverso la struttura \type{siginfo\_t}, utilizzando la forma estesa +\var{sa\_sigaction} del manipolatore (si riveda quanto illustrato in +\secref{sec:sig_sigaction}). + +Per far questo però occorre utilizzare le funzionalità dei segnali real-time +(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 +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 \type{siginfo\_t}, troverà nel campo \var{si\_fd} il valore del file -descriptor che ha generato il segnale. In questo modo è possibile identificare -immediatamente il file evitando completamente l'uso di funzioni come -\func{poll} o \func{select}. +descriptor che ha generato il segnale. + +Un secondo vantaggio dell'uso dei segnali real-time è che essendo dotati di +una coda di consegna ogni segnale sarà associato ad uno solo file descriptor; +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}, 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 le funzioni di I/O sono system call lente), essa è comunque limitata alla notifica della disponibilità del file descriptor per le operazioni di I/O, e non ad uno svolgimento asincrono delle medesime. Lo standard POSIX.1b -definisce invece una interfaccia apposita per l'I/O asincrono, che prevede un -insieme di funzioni dedicate, completamente separato rispetto a quelle usate +definisce anche una interfaccia apposita per l'I/O asincrono, che prevede un +insieme di funzioni dedicate, completamente separate rispetto a quelle usate normalmente. In generale questa interfaccia è completamente astratta e può essere @@ -380,11 +389,68 @@ implementata sia direttamente nel kernel, che in user space attraverso l'uso di thread. Al momento\footnote{fino ai kernel della serie 2.4.x, nella serie 2.5.x è però iniziato un lavoro completo di riscrittura di tutto il sistema di I/O, che prevede anche l'introduzione di un nuovo layer per l'I/O - asincrono.} esiste una sola versione stabile, quella delle \acr{glibc}, che -è realizzata completamente in user space; esistono comunque vari progetti -(come il KAIO della SGI, o i patch di Benjamin La Haise) che prevedono un -supporto diretto all'interno del kernel. + 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 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 inolte 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. + +Dato che l'I/O asincrono può supportare + + + +Le due funzioni principali dell'interfaccia sono quelle per la lettura e +scrittura, \func{aio\_read} e \func{aio\_write}, i cui prototipi sono: +\begin{functions} + \headdecl{aio.h} + \funcdecl{int aio\_read(struct aiocb *aiocbp)} + Richiede una lettura asincrona sul file specificato tramite \param{aiocbp}. + + \funcdecl{int aio\_write(struct aiocb *aiocbp)} + Richiede una scrittura asincrona sul file specificato tramite \param{aiocbp}. +\end{functions} @@ -393,7 +459,7 @@ supporto diretto all'interno 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