X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=21dc922ac683c4fe499ff8d417a41bd0a91bb84c;hp=6281f75cc96698557fa78bc3efa34bd4abbe5022;hb=9c6ea14a2d89e1cb76b4dd8683542f71c9dcf107;hpb=e15bf09623a78b9a5ddc5cef72d54fe1f4c411a2;ds=sidebyside

diff --git a/fileadv.tex b/fileadv.tex
index 6281f75..21dc922 100644
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -28,13 +28,13 @@ I/O possono bloccarsi indefinitamente.\footnote{si ricordi per
 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, e che non può
-essere risolto con le funzioni base trattate in
-\capref{cha:file_unix_interface}, è quello in cui si devono eseguire su più
-file descriptor operazioni che possono bloccarsi: 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.
+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à
@@ -53,18 +53,13 @@ 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 usarle però è comunque comunque necessario
-utilizzare la modalità di I/O non bloccante.
+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}
 
 
-%\section{I/O asincrono}
-%\label{sec:file_asynchronous}
-
-%Non supportato in Linux, in BSD e SRv4 c'è, ma usando il segnale \macro{SIGIO}
-%per indicare che i dati sono disponibili, 
 
 \subsection{L'I/O asincrono}
 \label{sec:file_asyncronous_io}
@@ -76,16 +71,17 @@ modalit
 di \func{fcntl}.
 
 In tal caso il sistema genera un segnale \macro{SIGIO} tutte le volte che sono
-presenti dei dati in input sul file.
-
-
-
-Uno dei problemi che si presentavano con le prime implementazioni di questa
-modalità di I/O è che essa poteva essere usata in maniera semplice con un solo
-file per processo, dato che altrimenti non sarebbe stato distinguere da quale
-file provieniva l'attività che ha causato l'emissione del segnale. 
-
-
+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.