X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=fd7799566362e68afd1aaf72ddcbccec604465ae;hp=2d000d8baa659e3a7e35f4bae109e3203262625b;hb=577f268d8395cbd4db85c3b9ca3a7b387ba4ff0f;hpb=6b93188c5ec74933664b7d47418d4e9d8902d580

diff --git a/fileadv.tex b/fileadv.tex
index 2d000d8..fd77995 100644
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -393,7 +393,7 @@ nel campo \var{revents} per notificare delle condizioni di errore.
     \const{POLLHUP}   & Si è verificato un hung-up.\\
     \const{POLLNVAL}  & Il file descriptor non è aperto.\\
     \hline
-    \const{POLLMSG}   & Definito per compatobilità con SysV.\\
+    \const{POLLMSG}   & Definito per compatibilità con SysV.\\
     \hline    
   \end{tabular}
   \caption{Costanti per l'identificazione dei vari bit dei campi
@@ -413,9 +413,9 @@ distinzione ha senso solo per i dati \textit{out-of-band} dei socket (vedi
 alle varie condizioni dei socket torneremo in \secref{sec:TCP_serv_poll}, dove
 vedremo anche un esempio del suo utilizzo. Si tenga conto comunque che le
 costanti relative ai diversi tipi di dati (come \macro{POLLRDNORM} e
-\macro{POLLRDBAND}) sono utilizzabili soltanto qualora si sia definito
-\macro{\_XOPEN\_SOURCE}.\footnote{e ci si ricordi di farlo sempre in testa al
-  file, definirla soltanto prima di includere \file{sys/poll.h} non è
+\macro{POLLRDBAND}) sono utilizzabili soltanto qualora si sia definita la
+macro \macro{\_XOPEN\_SOURCE}.\footnote{e ci si ricordi di farlo sempre in
+  testa al file, definirla soltanto prima di includere \file{sys/poll.h} non è
   sufficiente.}
 
 In caso di successo funzione ritorna restituendo il numero di file (un valore
@@ -441,9 +441,11 @@ le pi
 debba operare su più file contemporaneamente, esistono altre modalità di
 gestione delle stesse problematiche. In particolare sono importanti in questo
 contesto le modalità di accesso ai file eseguibili in maniera
-\textsl{asincrona}, senza cioè che un processo debba bloccarsi, ed utilizzi
-invece un meccanismo di notifica asincrono, come un segnale, per rilevare la
-possibilità di eseguire le operazioni volute.
+\textsl{asincrona}, quelle cioè in cui un processo non deve bloccarsi in
+attesa della disponibilità dell'accesso al file, ma può proseguire
+nell'esecuzione utilizzando invece un meccanismo di notifica asincrono (di
+norma un segnale), per essere avvisato della possibilità di eseguire le
+operazioni di I/O volute.
 
 
 \subsection{Operazioni asincrone sui file}
@@ -464,14 +466,15 @@ propriamente 
 notifica delle variazione dello stato del file descriptor aperto in questo
 modo.
 
-Quello che succede è che il sistema genera un segnale (normalmente
-\const{SIGIO}, ma è possibile usarne altri con il comando \const{F\_SETSIG} di
-\func{fcntl}) 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 \const{F\_SETOWN} di \func{fcntl}, quale processo (o gruppo di
-processi) riceverà il segnale. Se pertanto si effettuano le operazioni in
-risposta alla ricezione del segnale non ci sarà più la necessità di restare
-bloccati in attesa della disponibilità di accesso ai file.
+Quello che succede in questo caso è che il sistema genera un segnale
+(normalmente \const{SIGIO}, ma è possibile usarne altri con il comando
+\const{F\_SETSIG} di \func{fcntl}) 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 \const{F\_SETOWN} di \func{fcntl},
+quale processo (o gruppo di processi) riceverà il segnale. Se pertanto si
+effettuano le operazioni di I/O in risposta alla ricezione del segnale non ci
+sarà più la necessità di restare bloccati in attesa della disponibilità di
+accesso ai file.
 
 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
@@ -484,14 +487,15 @@ 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 i
 file descriptor sono più di uno, qual'è quello responsabile dell'emissione del
-segnale; inoltre dato che i segnali normali non si accumulano, in presenza di
-più file descriptor attivi contemporaneamente, più segnali emessi nello stesso
-tempo verrebbero notificati una volta sola. Linux però supporta le estensioni
-POSIX.1b dei segnali real-time, che possono accumularsi e che permettono di
-riconoscere il file descriptor facendo ricorso alle informazioni aggiuntive
-restituite attraverso la struttura \struct{siginfo\_t}, utilizzando la forma
-estesa \var{sa\_sigaction} del gestore (si riveda quanto illustrato in
-\secref{sec:sig_sigaction}).
+segnale. Inoltre dato che i segnali normali non si accodano (si ricordi quanto
+illustrato in sez.~\ref{sec:sig_notification}), in presenza di più file
+descriptor attivi contemporaneamente, più segnali emessi nello stesso momento
+verrebbero notificati una volta sola. Linux però supporta le estensioni
+POSIX.1b dei segnali real-time, che vengono accodati e che permettono di
+riconoscere il file descriptor che li ha emessi. In questo caso infatti si può
+fare ricorso alle informazioni aggiuntive restituite attraverso la struttura
+\struct{siginfo\_t}, utilizzando la forma estesa \var{sa\_sigaction} del
+gestore (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}) impostando esplicitamente con il comando
@@ -504,17 +508,18 @@ campo \var{si\_code}\footnote{il valore resta \const{SI\_SIGIO} qualunque sia
 \struct{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
+Un secondo vantaggio dell'uso dei segnali real-time è che essendo questi
+ultimi 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, dato che i segnali real-time supportano
+anche questa funzionalità. 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.  Se infatti si eccedono le dimensioni di quest'ultima, il kernel, non
 potendo più assicurare il comportamento corretto per un segnale real-time,
-invierà al suo posto un \const{SIGIO}, su cui si accumuleranno tutti i segnali
-in eccesso, e si dovrà determinare con un ciclo quali sono i file diventati
-attivi.
+invierà al suo posto un solo \const{SIGIO}, su cui si saranno accumulati tutti
+i segnali in eccesso, e si dovrà allora determinare con un ciclo quali sono i
+file diventati attivi.
 
 
 \subsection{L'interfaccia POSIX per l'I/O asincrono}