+Abbiamo visto in \secref{sec:sig_gen_beha}, affrontando la suddivisione fra
+\textit{fast} e \textit{slow} system call, che in certi casi le funzioni di
+I/O possono bloccarsi indefinitamente.\footnote{si ricordi però che questo può
+ accadere solo per le pipe, i socket ed alcuni file di dispositivo; sui file
+ normali le funzioni di lettura e scrittura ritornano sempre subito.} Ad
+esempio le operazioni di lettura possono bloccarsi quando non ci sono dati
+disponibili sul descrittore su cui si sta operando.
+
+Uno dei problemi più comuni che ci si trova ad affrontare, che non può essere
+risolto con le funzioni di base trattate in \capref{cha:file_unix_interface},
+è quello in cui si devono eseguire operazioni che possono bloccarsi su più
+file descriptor: il problema è che mentre si è bloccati su uno di questi file
+su di un'altro potrebbero essere presenti dei dati, così che nel migliore dei
+casi si avrebbe una lettura inutilmente ritardata, e nel peggiore si potrebbe
+addirittura arrivare ad un deadlock.
+
+Abbiamo già accennato in \secref{sec:file_open} che è possibile prevenire
+questo tipo di comportamento aprendo un file in modalità
+\textsl{non-bloccante}, specificando il flag \macro{O\_NONBLOCK} alla chiamata
+di \func{open}. In questo caso le funzioni di input/output che altrimenti si
+sarebbero bloccate ritornano immediatamente, restituendo l'errore
+\macro{EAGAIN}.
+
+L'utilizzo di questa modalità di I/O permette allora 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 \textit{polling}, è estremamente inefficiente: si tiene costantemente
+impiegata la CPU solo per eseguire in continuazione delle system call che
+nella gran parte dei casi falliranno.
+
+Per questo motivo, quando come vedremo in dettaglio in
+\secref{sec:file_multiplexing}, il sistema fornisce delle funzioni apposite
+che permettono di aggirare questo problema, permettendo di attendere fino alla
+disponibilità di un accesso; per poterle usare però è comunque comunque
+necessario utilizzare la modalità di I/O non bloccante all'apertura del file.
+
+\subsection{Le funzioni \func{poll} e \func{select}}
+\label{sec:file_multiplexing}
+
+
+
+\subsection{L'I/O asincrono}
+\label{sec:file_asyncronous_io}
+
+Una modalità alternativa all'uso dell'I/O non bloccante è quella di fare
+ricorso all'I/O asincrono. Abbiamo accennato in \secref{sec:file_open} che è
+possibile, attraverso l'uso del flag \macro{O\_ASYNC}, aprire un file in
+modalità asincrona, così come è possibile settare questo flag attraverso l'uso
+di \func{fcntl}.
+
+In tal caso il sistema genera un segnale \macro{SIGIO} tutte le volte che sono
+presenti dei dati in input su un file aperto in questa modalità. Uno dei
+problemi che si presentavano con le prime implementazioni di questa modalità
+di I/O è che essa poteva essere usata in maniera semplice aprendo un solo file
+per processo, dato che altrimenti si sarebbe dovuto provvedere ad effettuare
+una serie di controlli su tutti i file aperti per distinguere a quale fosse
+dovuto l'emissione del segnale.
+
+Tutto questo adesso può essere evitato facendo ricorso alle informazioni
+restituite al manipolatore del segnale attraverso la struttura
+\var{siginfo\_t} (vedi \figref{fig:sig_siginfo_t}), il cui campo \var{si\_fd}
+riporta il file descriptor che ha generato il segnale.
+
+
+
+\subsection{File mappati in memoria}
+\label{sec:file_memory_map}
+
+
+\subsection{I/O multiplo}
+\label{sec:file_multiple_io}
+