Una modalità alternativa all'uso dell'\textit{I/O multiplexing} per gestione
dell'I/O simultaneo su molti file è costituita dal 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.
+ asincrono} o ``AIO''. 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.
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
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 una interfaccia apposita per l'I/O asincrono
-vero e proprio, che prevede un insieme di funzioni dedicate per la lettura e
-la scrittura dei file, completamente separate rispetto a quelle usate
-normalmente.
+vero e proprio,\footnote{questa è stata ulteriormente perfezionata nelle
+ successive versioni POSIX.1-2001 e POSIX.1-2008.} che prevede un insieme di
+funzioni dedicate per la lettura e la scrittura dei file, 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 \itindex{thread} \textit{thread}. Per le versioni del kernel meno recenti
-esiste una implementazione di questa interfaccia fornita delle \acr{glibc},
-che è realizzata completamente in user space, ed è accessibile linkando i
-programmi con la libreria \file{librt}. Nelle versioni più recenti (a partire
-dalla 2.5.32) è stato introdotto direttamente nel kernel un nuovo layer per
-l'I/O asincrono.
-
-Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate
-attraverso l'uso di una apposita struttura \struct{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
-\headfile{aio.h}, è riportata in fig.~\ref{fig:file_aiocb}. Nello steso file è
-definita la macro \macro{\_POSIX\_ASYNCHRONOUS\_IO}, che dichiara la
-disponibilità dell'interfaccia per l'I/O asincrono.
+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
+\file{librt}. Nelle versioni più recenti (a partire dalla 2.5.32) è stato
+introdotto nel kernel un nuovo layer per l'I/O asincrono, ma ancora il
+supporto è parziale ed insufficiente ad implementare l'AIO POSIX.
+
+Lo standard POSIX prevede che tutte le operazioni di I/O asincrono siano
+controllate attraverso l'uso di una apposita struttura \struct{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 \headfile{aio.h}, è riportata in
+fig.~\ref{fig:file_aiocb}. Nello steso file è definita la macro
+\macro{\_POSIX\_ASYNCHRONOUS\_IO}, che dichiara la disponibilità
+dell'interfaccia per l'I/O asincrono.
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.90\textwidth}
\includestruct{listati/aiocb.h}
- \end{minipage}
+ \end{minipage}
\normalsize
\caption{La struttura \structd{aiocb}, usata per il controllo dell'I/O
asincrono.}
\funcd{aio\_read} ed \funcd{aio\_write}. Esse permettono di richiedere una
lettura od una scrittura asincrona di dati, usando la struttura \struct{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}.
+\begin{funcproto}{
+\fhead{aio.h}
+\fdecl{int aio\_read(struct aiocb *aiocbp)}
+\fdesc{Richiede una lettura asincrona.}
+\fdecl{int aio\_write(struct aiocb *aiocbp)}
+\fdesc{Richiede una scrittura asincrona.}
+}
- \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} assumerà uno dei valori:
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EBADF}] si è specificato un file descriptor sbagliato.
\item[\errcode{ENOSYS}] la funzione non è implementata.
\item[\errcode{EAGAIN}] la coda delle richieste è momentaneamente piena.
\end{errlist}
}
-\end{functions}
+\end{funcproto}
+
Entrambe le funzioni ritornano immediatamente dopo aver messo in coda la
richiesta, o in caso di errore. Non è detto che gli errori \errcode{EBADF} ed
richieste, impostando l'argomento \param{sig} in maniera analoga a come si fa
per il campo \var{aio\_sigevent} di \struct{aiocb}.
+% TODO: trattare libaio e le system call del kernel per l'I/O asincrono, vedi
+% http://lse.sourceforge.net/io/aio.html,
+% http://webfiveoh.com/content/guides/2012/aug/mon-13th/linux-asynchronous-io-and-libaio.html,
+% https://code.google.com/p/kernel/wiki/AIOUserGuide,
+% http://bert-hubert.blogspot.de/2012/05/on-linux-asynchronous-file-io.html
+
\section{Altre modalità di I/O avanzato}
\label{sec:file_advanced_io}
projects / gapil.git / blobdiff