+Una modalità alternativa all'uso dell'\textit{I/O multiplexing} è quella di
+fare ricorso al cosiddetto \textsl{I/O asincrono}. Il concetto base
+dell'\textsl{I/O asincrono} è che le funzioni di I/O non attendono il
+completamento delle operazioni prima di ritornare, così che il processo non
+viene bloccato. In questo modo diventa ad esempio possibile effettuare una
+richiesta preventiva di dati, in modo da poter effettuare in contemporanea le
+operazioni di calcolo e quelle di I/O.
+
+Abbiamo accennato in \secref{sec:file_open} che è possibile, attraverso l'uso
+del flag \macro{O\_ASYNC},\footnote{l'uso del flag di \macro{O\_ASYNC} e dei
+ comandi \macro{F\_SETOWN} e \macro{F\_GETOWN} per \func{fcntl} è specifico
+ di Linux e BSD.} aprire un file in modalità asincrona, così come è possibile
+attivare in un secondo tempo questa modalità settando questo flag attraverso
+l'uso di \func{fcntl} con il comando \macro{F\_SETFL} (vedi
+\secref{sec:file_fcntl}).
+
+In realtà in questo caso non si tratta di I/O asincrono vero e proprio, quanto
+di un meccanismo asincrono di notifica delle variazione dello stato del file
+descriptor; quello che succede è che il sistema genera un segnale (normalmente
+\macro{SIGIO}, ma è possibile usarne altri) tutte le volte che diventa
+possibile leggere o scrivere dal file descriptor che si è posto in questa
+modalità. Si può inoltre selezionare, con il comando \macro{F\_SETOWN} di
+\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, 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.
+
+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 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
+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 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.
+
+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 attivare 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 .}
+ \label{fig:file_sigevent}
+\end{figure}
+
+Infine il campo \var{aio\_sigevent} serve a specificare il modo in cui si
+vuole che la notifica del completamento delle operazioni richieste venga
+effettuata. 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 usando il segnale
+ specificato nel campo \var{sigev\_signo}.
+\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 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}.
+
+ \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 in uno
+ degli insiemi.
+ \item[\macro{ENOSYS}] La funzione è implementata.
+ \item[\macro{EINVAL}] Si è specificato un valore negativo non valido per i
+ campi \var{aio\_offset} o \var{aio\_reqprio}, di \param{aiocbp}.
+ \end{errlist}
+ ed inoltre \macro{ENOMEM}.}
+
+\end{functions}
+
projects / gapil.git / blobdiff