-\textit{fast} e \textit{slow} system call,\index{system~call~lente} 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\index{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.
-
-Questo comportamento causa uno dei problemi più comuni che ci si trova ad
-affrontare nelle operazioni di I/O, che si verifica quando si deve operare con
-più file descriptor eseguendo funzioni che possono bloccarsi senza che sia
-possibile prevedere quando questo può avvenire (il caso più classico è quello
-di un server in attesa di dati in ingresso da vari client). Quello che può
-accadere è di restare bloccati nell'eseguire una operazione su un file
-descriptor che non è ``\textsl{pronto}'', quando ce ne potrebbe essere un
-altro disponibile. Questo comporta nel migliore dei casi una operazione
-ritardata inutilmente nell'attesa del completamento di quella bloccata, mentre
-nel peggiore dei casi (quando la conclusione della operazione bloccata dipende
-da quanto si otterrebbe dal file descriptor ``\textsl{disponibile}'') si
-potrebbe addirittura arrivare ad un \itindex{deadlock} \textit{deadlock}.
+\textit{fast} e \textit{slow} \textit{system call},\index{system~call~lente}
+che in certi casi le funzioni di I/O eseguite su un file descritor possono
+bloccarsi indefinitamente. Questo non avviene mai per i file normali, per i
+quali le funzioni di lettura e scrittura ritornano sempre subito, ma può
+avvenire per alcuni \index{file!di~dispositivo} file di dispositivo, come ad
+esempio una seriale, o con l'uso di file descriptor collegati a meccanismi di
+intercomunicazione come le \textit{pipe} (vedi sez.~\ref{sec:ipc_unix}) ed i
+socket (vedi sez.~\ref{sec:sock_socket_def}). In casi come questi ad esempio
+una operazione di lettura potrebbe bloccarsi se non ci sono dati disponibili
+sul descrittore su cui la si sta effettuando.
+
+Questo comportamento è alla radice di una delle problematiche più comuni che
+ci si trova ad affrontare nelle operazioni di I/O, la necessità di operare su
+su più file descriptor eseguendo funzioni che possono bloccarsi
+indefinitamente senza che sia possibile prevedere quando questo può avvenire;
+un caso classico è quello di un server di rete (tratteremo la problematica in
+dettaglio nella seconda parte della guida) in attesa di dati in ingresso
+prevenienti da vari client.
+
+In un caso di questo tipo, se si andasse ad operare sui vari file descriptor
+aperti uno dopo l'altro, potrebbe accadere di restare bloccati nell'eseguire
+una lettura su uno di quelli che non è ``\textsl{pronto}'', quando ce ne
+potrebbe essere un altro con dati disponibili. Questo comporta nel migliore
+dei casi una operazione ritardata inutilmente nell'attesa del completamento di
+quella bloccata, mentre nel peggiore dei casi (quando la conclusione della
+operazione bloccata dipende da quanto si otterrebbe dal file descriptor
+``\textsl{disponibile}'') si potrebbe addirittura arrivare ad un
+\itindex{deadlock} \textit{deadlock}.