Ultima parte delle correzioni di Fabio Rossi
[gapil.git] / signal.tex
index 182de6abc4678a16eaa0c71b3fcf313c91f928d8..2e24f3653f104d5d55f977095553a4fed6bf5cd9 100644 (file)
@@ -892,7 +892,7 @@ gestore \param{handler} invece, oltre all'indirizzo della funzione da chiamare
 all'occorrenza del segnale, può assumere anche i due valori costanti
 \const{SIG\_IGN} con cui si dice ignorare il segnale e \const{SIG\_DFL} per
 reinstallare l'azione predefinita.\footnote{si ricordi però che i due segnali
-  \const{SIGKILL} e \const{SIGSTOP} non possono essere ignorati né
+  \const{SIGKILL} e \const{SIGSTOP} non possono essere né ignorati né
   intercettati; l'uso di \const{SIG\_IGN} per questi segnali non ha alcun
   effetto.}
 
@@ -1076,10 +1076,9 @@ segnale; siccome alla chiamata viene cancellato ogni precedente allarme,
 questo può essere usato per cancellare una programmazione precedente. 
 
 La funzione inoltre ritorna il numero di secondi rimanenti all'invio
-dell'allarme precedentemente programmato, in modo che sia possibile
-controllare se non si cancella un precedente allarme ed eventualmente
-predisporre le opportune misure per gestire il caso di necessità di più
-interruzioni.
+dell'allarme programmato in precedenza. In questo modo è possibile controllare
+se non si è cancellato un precedente allarme ed predisporre eventuali misure
+che permettano di gestire il caso in cui servono più interruzioni.
 
 In sez.~\ref{sec:sys_unix_time} abbiamo visto che ad ogni processo sono
 associati tre tempi diversi: il \textit{clock time}, l'\textit{user time} ed
@@ -1411,7 +1410,7 @@ di zombie\index{zombie}.
   \end{minipage}
   \normalsize 
   \caption{Codice di una funzione generica di gestione per il segnale
-    \texttt{SIGCHLD}.}  
+    \texttt{SIGCHLD}.}
   \label{fig:sig_sigchld_handl}
 \end{figure}
 
@@ -1421,7 +1420,7 @@ comincia (\texttt{\small 6--7}) con il salvare lo stato corrente di
 \var{errno}, in modo da poterlo ripristinare prima del ritorno del gestore
 (\texttt{\small 16--17}). In questo modo si preserva il valore della variabile
 visto dal corso di esecuzione principale del processo, che altrimenti sarebbe
-sovrascritto dal valore restituito nella successiva chiamata di \func{wait}.
+sovrascritto dal valore restituito nella successiva chiamata di \func{waitpid}.
 
 Il compito principale del gestore è quello di ricevere lo stato di
 terminazione del processo, cosa che viene eseguita nel ciclo in
@@ -1437,7 +1436,7 @@ Questo pu
 che molti processi figli terminino in rapida successione. Esso inoltre si
 presenta tutte le volte che un segnale viene bloccato: per quanti siano i
 segnali emessi durante il periodo di blocco, una volta che quest'ultimo sarà
-rimosso sarà recapitato un solo segnale.
+rimosso verrà recapitato un solo segnale.
 
 Allora, nel caso della terminazione dei processi figli, se si chiamasse
 \func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un
@@ -1502,8 +1501,8 @@ l'interruzione di \func{pause} venisse causata da un altro segnale.
 Questo codice però, a parte il non gestire il caso in cui si è avuta una
 precedente chiamata a \func{alarm} (che si è tralasciato per brevità),
 presenta una pericolosa race condition\index{\textit{race~condition}}.
-Infatti se il processo viene interrotto fra la chiamata di \func{alarm} e
-\func{pause} può capitare (ad esempio se il sistema è molto carico) che il
+Infatti, se il processo viene interrotto fra la chiamata di \func{alarm} e
+\func{pause}, può capitare (ad esempio se il sistema è molto carico) che il
 tempo di attesa scada prima dell'esecuzione di quest'ultima, cosicché essa
 sarebbe eseguita dopo l'arrivo di \const{SIGALRM}. In questo caso ci si
 troverebbe di fronte ad un deadlock\index{\textit{deadlock}}, in quanto
@@ -1565,10 +1564,11 @@ segnale, e prendere le relative azioni conseguenti (\texttt{\small 6-11}).
 
 Questo è il tipico esempio di caso, già citato in
 sez.~\ref{sec:proc_race_cond}, in cui si genera una
-\index{\textit{race~condition}}race condition; se infatti il segnale arriva
-immediatamente dopo l'esecuzione del controllo (\texttt{\small 6}) ma prima
-della cancellazione del flag (\texttt{\small 7}), la sua occorrenza sarà
-perduta.
+\index{\textit{race~condition}}race condition; infatti, in una situazione in
+cui un segnale è già arrivato (e \var{flag} è già ad 1) se un altro segnale
+segnale arriva immediatamente dopo l'esecuzione del controllo (\texttt{\small
+  6}) ma prima della cancellazione del flag (\texttt{\small 7}), la sua
+occorrenza sarà perduta.
 
 Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono
 funzioni più sofisticate di quelle illustrate finora, che hanno origine dalla
@@ -1879,7 +1879,7 @@ estremamente semplice, 
 
 \index{\textit{signal mask}|(}
 Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like
-permettono si bloccare temporaneamente (o di eliminare completamente,
+permettono di bloccare temporaneamente (o di eliminare completamente,
 impostando \const{SIG\_IGN} come azione) la consegna dei segnali ad un
 processo. Questo è fatto specificando la cosiddetta \textsl{maschera dei
   segnali} (o \textit{signal mask}) del processo\footnote{nel caso di Linux
@@ -2145,7 +2145,7 @@ sullo stack alternativo (nel qual caso non 
 
 In genere si installa uno stack alternativo per i segnali quando si teme di
 avere problemi di esaurimento dello stack standard o di superamento di un
-limite imposto con chiamata de tipo \code{setrlimit(RLIMIT\_STACK, \&rlim)}.
+limite imposto con chiamate del tipo \code{setrlimit(RLIMIT\_STACK, \&rlim)}.
 In tal caso infatti si avrebbe un segnale di \const{SIGSEGV}, che potrebbe
 essere gestito soltanto avendo abilitato uno stack alternativo.