X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=signal.tex;h=d1c76cb4afefd5f5d11b9c27b84d6776dba399d5;hb=ed54132fb0762894a86b100023f9d04fc4028975;hp=b4e869f818714f40360ff416284cad7b27ca10e0;hpb=4cbeb0e4fa1d31da798c8e68108eb6785586ab34;p=gapil.git

diff --git a/signal.tex b/signal.tex
index b4e869f..d1c76cb 100644
--- a/signal.tex
+++ b/signal.tex
@@ -806,14 +806,15 @@ gestore; viene mantenuto invece ogni eventuale impostazione dell'azione a
 programmi eseguiti in background, che altrimenti sarebbero interrotti da una
 successiva pressione di \texttt{C-c} o \texttt{C-y}.
 
-Per quanto riguarda il comportamento di tutte le altre system call si danno
-sostanzialmente due casi, a seconda che esse siano \index{system~call~lente}
-\textsl{lente} (\textit{slow}) o \textsl{veloci} (\textit{fast}). La gran
-parte di esse appartiene a quest'ultima categoria, che non è influenzata
-dall'arrivo di un segnale. Esse sono dette \textsl{veloci} in quanto la loro
-esecuzione è sostanzialmente immediata; la risposta al segnale viene sempre
-data dopo che la system call è stata completata, in quanto attendere per
-eseguire un gestore non comporta nessun inconveniente.
+Per quanto riguarda il comportamento di tutte le altre \textit{system call} si
+danno sostanzialmente due casi, a seconda che esse siano
+\index{system~call~lente} \textsl{lente} (\textit{slow}) o \textsl{veloci}
+(\textit{fast}). La gran parte di esse appartiene a quest'ultima categoria,
+che non è influenzata dall'arrivo di un segnale. Esse sono dette
+\textsl{veloci} in quanto la loro esecuzione è sostanzialmente immediata; la
+risposta al segnale viene sempre data dopo che la \textit{system call} è stata
+completata, in quanto attendere per eseguire un gestore non comporta nessun
+inconveniente.
 
 In alcuni casi però alcune system call (che per questo motivo vengono chiamate
 \textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può
@@ -1064,9 +1065,9 @@ Una seconda funzione che può essere definita in termini di \func{kill} è
 \end{table}
 
 Solo l'amministratore può inviare un segnale ad un processo qualunque, in
-tutti gli altri casi l'user-ID reale o l'user-ID effettivo del processo
-chiamante devono corrispondere all'user-ID reale o all'user-ID salvato della
-destinazione. Fa eccezione il caso in cui il segnale inviato sia
+tutti gli altri casi l'\acr{uid} reale o l'\acr{uid} effettivo del processo
+chiamante devono corrispondere all'\acr{uid} reale o all'\acr{uid} salvato
+della destinazione. Fa eccezione il caso in cui il segnale inviato sia
 \signal{SIGCONT}, nel quale occorre che entrambi i processi appartengano alla
 stessa sessione. Inoltre, dato il ruolo fondamentale che riveste nel sistema
 (si ricordi quanto visto in sez.~\ref{sec:sig_termination}), non è possibile
@@ -1438,24 +1439,25 @@ conclusione di un processo è quella di inviare questo segnale al
 padre.\footnote{in realtà in SVr4 eredita la semantica di System V, in cui il
   segnale si chiama \signal{SIGCLD} e viene trattato in maniera speciale; in
   System V infatti se si imposta esplicitamente l'azione a \const{SIG\_IGN} il
-  segnale non viene generato ed il sistema non genera \index{zombie} zombie
-  (lo stato di terminazione viene scartato senza dover chiamare una
-  \func{wait}).  L'azione predefinita è sempre quella di ignorare il segnale,
-  ma non attiva questo comportamento. Linux, come BSD e POSIX, non supporta
-  questa semantica ed usa il nome di \signal{SIGCLD} come sinonimo di
+  segnale non viene generato ed il sistema non genera \itindex{zombie}
+  \textit{zombie} (lo stato di terminazione viene scartato senza dover
+  chiamare una \func{wait}).  L'azione predefinita è sempre quella di ignorare
+  il segnale, ma non attiva questo comportamento. Linux, come BSD e POSIX, non
+  supporta questa semantica ed usa il nome di \signal{SIGCLD} come sinonimo di
   \signal{SIGCHLD}.} In generale dunque, quando non interessa elaborare lo
 stato di uscita di un processo, si può completare la gestione della
 terminazione installando un gestore per \signal{SIGCHLD} il cui unico compito
 sia quello di chiamare \func{waitpid} per completare la procedura di
-terminazione in modo da evitare la formazione di \index{zombie} zombie.
+terminazione in modo da evitare la formazione di \itindex{zombie}
+\textit{zombie}.
 
 In fig.~\ref{fig:sig_sigchld_handl} è mostrato il codice contenente una
-implementazione generica di una funzione di gestione per \signal{SIGCHLD}, (che
-si trova nei sorgenti allegati nel file \file{SigHand.c}); se ripetiamo i test
-di sez.~\ref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione
-\cmd{-s} (che si limita ad effettuare l'installazione di questa funzione come
-gestore di \signal{SIGCHLD}) potremo verificare che non si ha più la creazione
-di \index{zombie} zombie.
+implementazione generica di una funzione di gestione per \signal{SIGCHLD},
+(che si trova nei sorgenti allegati nel file \file{SigHand.c}); se ripetiamo i
+test di sez.~\ref{sec:proc_termination}, invocando \cmd{forktest} con
+l'opzione \cmd{-s} (che si limita ad effettuare l'installazione di questa
+funzione come gestore di \signal{SIGCHLD}) potremo verificare che non si ha
+più la creazione di \itindex{zombie} \textit{zombie}.
 
 \begin{figure}[!htbp]
   \footnotesize  \centering
@@ -1495,7 +1497,8 @@ 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
 solo processo, anche se i processi terminati sono più di uno, e gli altri
-resterebbero in stato di \index{zombie} zombie per un tempo indefinito.
+resterebbero in stato di \itindex{zombie} \textit{zombie} per un tempo
+indefinito.
 
 Per questo occorre ripetere la chiamata di \func{waitpid} fino a che essa non
 ritorni un valore nullo, segno che non resta nessun processo di cui si debba
@@ -1814,8 +1817,8 @@ tab.~\ref{tab:sig_sa_flag}.
                            \var{sa\_sigaction} al posto di
                            \var{sa\_handler}.\\
     \const{SA\_NOCLDWAIT}& Se il segnale è \signal{SIGCHLD} allora i processi
-                           figli non diventano \textit{zombie} quando
-                           terminano.\footnotemark \\ 
+                           figli non diventano \itindex{zombie}
+                           \textit{zombie} quando terminano.\footnotemark \\ 
     \hline
   \end{tabular}
   \caption{Valori del campo \var{sa\_flag} della struttura \struct{sigaction}.}
@@ -2420,7 +2423,7 @@ fig.~\ref{fig:sig_siginfo_t}, nella trattazione dei gestori in forma estesa.
 
 In particolare i campi utilizzati dai segnali \textit{real-time} sono
 \var{si\_pid} e \var{si\_uid} in cui vengono memorizzati rispettivamente il
-\acr{pid} e l'user-ID effettivo del processo che ha inviato il segnale, mentre
+\acr{pid} e l'\acr{uid} effettivo del processo che ha inviato il segnale, mentre
 per la restituzione dei dati viene usato il campo \var{si\_value}.
 
 \begin{figure}[!htb]
@@ -3389,6 +3392,10 @@ parte l'uso di \type{sigjmp\_buf} per \param{env}, è assolutamente identica a
 \func{longjmp}.
 
 
+% TODO: se e quando si troverà un argomento adeguato inserire altre funzioni
+% sparse attinenti ai segnali, al momento sono note solo:
+% * sigreturn (funzione interna, scarsamente interessante)
+% argomento a priorità IDLE (fare quando non resta niente altro da trattare)
 
 
 % LocalWords:  kernel POSIX timer shell control ctrl kill raise signal handler