Modifiche e aggiunte all'esempio

[gapil.git] / signal.tex

diff --git a/signal.tex b/signal.tex
index 0e1c42a1c850a29fb70ef7c7d0af6e5857887edd..fec20a72c0d0465508faae3bda50031b4a894bc8 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -1285,7 +1285,7 @@ aspettare.
 In alcune implementazioni inoltre l'uso di \func{sleep} può avere conflitti
 con quello di \macro{SIGALRM}, dato che la funzione può essere realizzata con
 l'uso di \func{pause} e \func{alarm} (in maniera analoga all'esempio che
-vedremo in \ref{sec:sig_example}). In tal caso mescolare chiamata di
+vedremo in \secref{sec:sig_example}). In tal caso mescolare chiamata di
 \func{alarm} e \func{sleep} o modificare l'azione di \macro{SIGALRM}, può
 causare risultati indefiniti. Nel caso delle \acr{glibc} è stata usata una
 implementazione completamente indipendente e questi problemi non ci sono.
@@ -1387,7 +1387,7 @@ padre.\footnote{in realt
   il nome di \macro{SIGCLD} come sinonimo di \macro{SIGCHLD}.} In generale
 dunque, quando non interessa elaborare lo stato di uscita di un processo, si
 può completare la gestione della terminazione installando un manipolatore per
-\macro{SIGCHLD} il cui unico compito sia quello chiamare \func{wait} per
+\macro{SIGCHLD} il cui unico compito sia quello chiamare \func{waitpid} per
 completare la procedura di terminazione in modo da evitare la formazione di
 zombie.
 
@@ -1442,7 +1442,7 @@ void Hand_CHLD(int sig)
 \end{figure}
 
 Il codice del manipolatore è di lettura immediata; come buona norma di
-programmazione (si ricordi quanto accennato \ref{sec:sys_errno}) si comincia
+programmazione (si ricordi quanto accennato \secref{sec:sys_errno}) si comincia
 (\texttt{\small 13}) con il salvare lo stato corrente di \var{errno}, in modo
 da poterla ripristinare prima del ritorno del manipolatore (\texttt{\small
   23}). In questo modo si preserva il valore della variabile visto dal corso
@@ -1461,15 +1461,23 @@ normalmente i segnali vengono ``fusi'' insieme ed al processo ne viene
 recapitato soltanto uno.
 
 Questo può essere un caso comune proprio con \texttt{SIGCHLD}, quando molti
-processi figli terminano in rapida successione, e si presenta comunque tutte
-le volte che un segnale viene bloccato. Nel nostro caso se si chiamasse
-\func{waitpid} una sola volta si correrebbe il rischio di non leggere lo stato
-di uscita di tutti i processi effettivamente terminati, i cui segnali sono
-stati riuniti in uno solo. Per questo il ciclo di (\texttt{\small 15--21})
-ripete la lettura (eseguita con il parametro \macro{WNOHANG}, che permette di
-evitare il blocco della funzione) fintanto che essa non restitusce un valore
-nullo, segno che non resta nessun processo concluso di cui si debba ancora
-ricevere lo stato di terminazione.
+processi figli terminano in rapida successione. Esso comunque si presenta
+tutte le volte che un segnale viene bloccato: per quanti siano i segnali
+emessi durante il periodo di blocco, una volta che esso viene rimosso ne sarà
+recapitato uno solo.
+
+Nel caso della terminazione dei processi figli, se si chiamasse \func{waitpid}
+una sola volta, essa leggerebbe un solo stato di teminazione, anche se i
+processi terminati sono più di uno, con relativa possibilità di avere zombie
+che non vengono eliminati. 
+
+Per questo si esegue un ciclo (\texttt{\small 15--21}) in cui ripete la
+lettura fintanto che essa non restituisce un valore nullo (si veda
+\secref{sec:proc_wait} per la sintassi della funzione) segno che non resta
+nessun processo di cui si debba ancora ricevere lo stato di terminazione. Si
+noti come la funzione viene invocata con il parametro \macro{WNOHANG} che
+permette di evitare che essa si blocchi quando tutti gli stati di terminazione
+sono stati ricevuti.
 
 
 \section{Gestione avanzata}