Si prosegue con la reindicizzazione delle funzioni, con relativa revizione
[gapil.git] / signal.tex
index a595a54d9d1cd8c8cb29a9c44efc78e3ebe8c7c4..a5363ec14f4cc3a1d1f863b6bcb29ead58da39fe 100644 (file)
@@ -143,7 +143,7 @@ moderno) il gestore una volta installato resta attivo e non si hanno
 tutti i problemi precedenti. In questa semantica i segnali vengono
 \textsl{generati} dal kernel per un processo all'occorrenza dell'evento che
 causa il segnale. In genere questo viene fatto dal kernel impostando l'apposito
 tutti i problemi precedenti. In questa semantica i segnali vengono
 \textsl{generati} dal kernel per un processo all'occorrenza dell'evento che
 causa il segnale. In genere questo viene fatto dal kernel impostando l'apposito
-campo della \var{task\_struct} del processo nella process table (si veda
+campo della \struct{task\_struct} del processo nella process table (si veda
 \figref{fig:proc_task_struct}).
 
 Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
 \figref{fig:proc_task_struct}).
 
 Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
@@ -152,7 +152,7 @@ per tutto il tempo che passa fra la generazione del segnale e la sua consegna
 esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
 procedura viene effettuata dallo scheduler\index{scheduler} quando,
 riprendendo l'esecuzione del processo in questione, verifica la presenza del
 esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
 procedura viene effettuata dallo scheduler\index{scheduler} quando,
 riprendendo l'esecuzione del processo in questione, verifica la presenza del
-segnale nella \var{task\_struct} e mette in esecuzione il gestore.
+segnale nella \struct{task\_struct} e mette in esecuzione il gestore.
 
 In questa semantica un processo ha la possibilità di bloccare la consegna dei
 segnali, in questo caso, se l'azione per il suddetto segnale non è quella di
 
 In questa semantica un processo ha la possibilità di bloccare la consegna dei
 segnali, in questo caso, se l'azione per il suddetto segnale non è quella di
@@ -215,7 +215,7 @@ internamente o esternamente al processo.
 
 Come accennato quando un segnale viene generato, se la sua azione predefinita
 non è quella di essere ignorato, il kernel prende nota del fatto nella
 
 Come accennato quando un segnale viene generato, se la sua azione predefinita
 non è quella di essere ignorato, il kernel prende nota del fatto nella
-\var{task\_struct} del processo; si dice così che il segnale diventa
+\struct{task\_struct} del processo; si dice così che il segnale diventa
 \textsl{pendente} (o \textit{pending}), e rimane tale fino al momento in cui
 verrà notificato al processo (o verrà specificata come azione quella di
 ignorarlo).
 \textsl{pendente} (o \textit{pending}), e rimane tale fino al momento in cui
 verrà notificato al processo (o verrà specificata come azione quella di
 ignorarlo).
@@ -394,7 +394,8 @@ stato dello stack e delle variabili al momento della ricezione del segnale.
     \const{SIGPROF}  &SL & A & Timer del profiling scaduto                   \\
     \const{SIGSYS}   &SL & C & Argomento sbagliato per una subroutine (SVID) \\
     \const{SIGTRAP}  &SL & C & Trappole per un Trace/breakpoint              \\
     \const{SIGPROF}  &SL & A & Timer del profiling scaduto                   \\
     \const{SIGSYS}   &SL & C & Argomento sbagliato per una subroutine (SVID) \\
     \const{SIGTRAP}  &SL & C & Trappole per un Trace/breakpoint              \\
-    \const{SIGURG}   &SLB& B & Ricezione di una urgent condition su un socket\\
+    \const{SIGURG}   &SLB& B & Ricezione di una \textit{urgent condition} su 
+                               un socket\index{socket}\\
     \const{SIGVTALRM}&SLB& A & Virtual alarm clock                           \\
     \const{SIGXCPU}  &SLB& C & Ecceduto il limite sul CPU time               \\
     \const{SIGXFSZ}  &SLB& C & Ecceduto il limite sulla dimensione dei file  \\
     \const{SIGVTALRM}&SLB& A & Virtual alarm clock                           \\
     \const{SIGXCPU}  &SLB& C & Ecceduto il limite sul CPU time               \\
     \const{SIGXFSZ}  &SLB& C & Ecceduto il limite sulla dimensione dei file  \\
@@ -431,11 +432,11 @@ proibita) e l'esecuzione non pu
 
 In genere si intercettano questi segnali per permettere al programma di
 terminare in maniera pulita, ad esempio per ripristinare le impostazioni della
 
 In genere si intercettano questi segnali per permettere al programma di
 terminare in maniera pulita, ad esempio per ripristinare le impostazioni della
-console o eliminare i file di lock prima dell'uscita.  In questo caso il
-gestore deve concludersi ripristinando l'azione predefinita e rialzando il
-segnale, in questo modo il programma si concluderà senza effetti spiacevoli,
-ma riportando lo stesso stato di uscita che avrebbe avuto se il gestore non ci
-fosse stato.
+console o eliminare i file di lock\index{file!di lock} prima dell'uscita.  In
+questo caso il gestore deve concludersi ripristinando l'azione predefinita e
+rialzando il segnale, in questo modo il programma si concluderà senza effetti
+spiacevoli, ma riportando lo stesso stato di uscita che avrebbe avuto se il
+gestore non ci fosse stato.
 
 L'azione predefinita per tutti questi segnali è causare la terminazione del
 processo che li ha causati. In genere oltre a questo il segnale provoca pure
 
 L'azione predefinita per tutti questi segnali è causare la terminazione del
 processo che li ha causati. In genere oltre a questo il segnale provoca pure
@@ -591,12 +592,13 @@ generare questi segnali.
 L'azione predefinita è di essere ignorati. Questi segnali sono:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\const{SIGIO}] Questo segnale viene inviato quando un file descriptor è
 L'azione predefinita è di essere ignorati. Questi segnali sono:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\const{SIGIO}] Questo segnale viene inviato quando un file descriptor è
-  pronto per eseguire dell'input/output. In molti sistemi solo i socket e i
-  terminali possono generare questo segnale, in Linux questo può essere usato
-  anche per i file, posto che la \func{fcntl} abbia avuto successo.
+  pronto per eseguire dell'input/output. In molti sistemi solo i
+  socket\index{socket} e i terminali possono generare questo segnale, in Linux
+  questo può essere usato anche per i file, posto che la \func{fcntl} abbia
+  avuto successo.
 \item[\const{SIGURG}] Questo segnale è inviato quando arrivano dei dati
 \item[\const{SIGURG}] Questo segnale è inviato quando arrivano dei dati
-  urgenti o \textit{out of band} su di un socket; per maggiori dettagli al
-  proposito si veda \secref{sec:xxx_urgent_data}.
+  urgenti o \textit{out of band} su di un socket\index{socket}; per maggiori
+  dettagli al proposito si veda \secref{sec:xxx_urgent_data}.
 \item[\const{SIGPOLL}] Questo segnale è equivalente a \const{SIGIO}, è
   definito solo per compatibilità con i sistemi System V.
 \end{basedescript}
 \item[\const{SIGPOLL}] Questo segnale è equivalente a \const{SIGIO}, è
   definito solo per compatibilità con i sistemi System V.
 \end{basedescript}
@@ -718,7 +720,7 @@ GNU, accessibile avendo definito \macro{\_GNU\_SOURCE}, ed 
 funzione \func{strerror} (si veda \secref{sec:sys_strerror}) per gli errori:
 \begin{prototype}{string.h}{char *strsignal(int signum)} 
   Ritorna il puntatore ad una stringa che contiene la descrizione del segnale
 funzione \func{strerror} (si veda \secref{sec:sys_strerror}) per gli errori:
 \begin{prototype}{string.h}{char *strsignal(int signum)} 
   Ritorna il puntatore ad una stringa che contiene la descrizione del segnale
-  \var{signum}.
+  \param{signum}.
 \end{prototype}
 \noindent dato che la stringa è allocata staticamente non se ne deve
 modificare il contenuto, che resta valido solo fino alla successiva chiamata
 \end{prototype}
 \noindent dato che la stringa è allocata staticamente non se ne deve
 modificare il contenuto, che resta valido solo fino alla successiva chiamata
@@ -807,7 +809,8 @@ eseguito prima che la system call sia ritornata.  Un elenco dei casi in cui si
 presenta questa situazione è il seguente:
 \begin{itemize}
 \item la lettura da file che possono bloccarsi in attesa di dati non ancora
 presenta questa situazione è il seguente:
 \begin{itemize}
 \item la lettura da file che possono bloccarsi in attesa di dati non ancora
-  presenti (come per certi file di dispositivo, i socket o le pipe).
+  presenti (come per certi file di dispositivo\index{file!di dispositivo}, i
+  socket\index{socket} o le pipe).
 \item la scrittura sugli stessi file, nel caso in cui dati non possano essere
   accettati immediatamente.
 \item l'apertura di un file di dispositivo che richiede operazioni non
 \item la scrittura sugli stessi file, nel caso in cui dati non possano essere
   accettati immediatamente.
 \item l'apertura di un file di dispositivo che richiede operazioni non
@@ -1131,14 +1134,14 @@ illustrati in precedenza usare; i possibili valori sono riportati in
   \label{tab:sig_setitimer_values}
 \end{table}
 
   \label{tab:sig_setitimer_values}
 \end{table}
 
-Il valore della struttura specificata \param{value} viene usato per impostare il
-timer, se il puntatore \param{ovalue} non è nullo il precedente valore viene
-salvato qui. I valori dei timer devono essere indicati attraverso una
-struttura \type{itimerval}, definita in \figref{fig:file_stat_struct}.
+Il valore della struttura specificata \param{value} viene usato per impostare
+il timer, se il puntatore \param{ovalue} non è nullo il precedente valore
+viene salvato qui. I valori dei timer devono essere indicati attraverso una
+struttura \struct{itimerval}, definita in \figref{fig:file_stat_struct}.
 
 La struttura è composta da due membri, il primo, \var{it\_interval} definisce
 il periodo del timer; il secondo, \var{it\_value} il tempo mancante alla
 
 La struttura è composta da due membri, il primo, \var{it\_interval} definisce
 il periodo del timer; il secondo, \var{it\_value} il tempo mancante alla
-scadenza. Entrambi esprimono i tempi tramite una struttura \var{timeval} che
+scadenza. Entrambi esprimono i tempi tramite una struttura \struct{timeval} che
 permette una precisione fino al microsecondo.
 
 Ciascun timer decrementa il valore di \var{it\_value} fino a zero, poi invia
 permette una precisione fino al microsecondo.
 
 Ciascun timer decrementa il valore di \var{it\_value} fino a zero, poi invia
@@ -1158,8 +1161,8 @@ struct itimerval
     \end{lstlisting}
   \end{minipage} 
   \normalsize 
     \end{lstlisting}
   \end{minipage} 
   \normalsize 
-  \caption{La struttura \type{itimerval}, che definisce i valori dei timer di
-    sistema.} 
+  \caption{La struttura \structd{itimerval}, che definisce i valori dei timer
+    di sistema.}
   \label{fig:sig_itimerval}
 \end{figure}
 
   \label{fig:sig_itimerval}
 \end{figure}
 
@@ -1345,7 +1348,7 @@ Lo standard richiede che la funzione sia implementata in maniera del tutto
 indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto
   utilizzando direttamente il timer del kernel.} e sia utilizzabile senza
 interferenze con l'uso di \const{SIGALRM}. La funzione prende come parametri
 indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto
   utilizzando direttamente il timer del kernel.} e sia utilizzabile senza
 interferenze con l'uso di \const{SIGALRM}. La funzione prende come parametri
-delle strutture di tipo \var{timespec}, la cui definizione è riportata in
+delle strutture di tipo \struct{timespec}, la cui definizione è riportata in
 \figref{fig:sys_timeval_struct}, che permettono di specificare un tempo con
 una precisione (teorica) fino al nanosecondo.
 
 \figref{fig:sys_timeval_struct}, che permettono di specificare un tempo con
 una precisione (teorica) fino al nanosecondo.
 
@@ -1381,16 +1384,16 @@ conclusione di un processo 
 padre.\footnote{in realtà in SVr4 eredita la semantica di System V, in cui il
   segnale si chiama \const{SIGCLD} e viene trattato in maniera speciale; in
   System V infatti se si imposta esplicitamente l'azione a \const{SIG\_IGN} il
 padre.\footnote{in realtà in SVr4 eredita la semantica di System V, in cui il
   segnale si chiama \const{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 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 \const{SIGCLD} come sinonimo di \const{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
-\const{SIGCHLD} il cui unico compito sia quello chiamare \func{waitpid} per
-completare la procedura di terminazione in modo da evitare la formazione di
-zombie.
+  segnale non viene generato ed il sistema non genera zombie\index{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 \const{SIGCLD} come sinonimo di \const{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 \const{SIGCHLD} il cui unico compito sia quello chiamare
+\func{waitpid} per completare la procedura di terminazione in modo da evitare
+la formazione di zombie\index{zombie}.
 
 In \figref{fig:sig_sigchld_handl} è mostrato il codice contenente una
 implementazione generica di una routine di gestione per \const{SIGCHLD}, (che
 
 In \figref{fig:sig_sigchld_handl} è mostrato il codice contenente una
 implementazione generica di una routine di gestione per \const{SIGCHLD}, (che
@@ -1398,7 +1401,7 @@ si trova nei sorgenti allegati nel file \file{SigHand.c}); se ripetiamo i test
 di \secref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione
 \cmd{-s} (che si limita ad effettuare l'installazione di questa funzione come
 gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione
 di \secref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione
 \cmd{-s} (che si limita ad effettuare l'installazione di questa funzione come
 gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione
-di zombie.
+di zombie\index{zombie}.
 
 %  è pertanto
 % naturale usare un esempio che ci permette di concludere la trattazione della
 
 %  è pertanto
 % naturale usare un esempio che ci permette di concludere la trattazione della
@@ -1406,16 +1409,9 @@ di zombie.
 % In questo caso si è tratterà di illustrare un esempio relativo ad un
 % gestore per che è previsto ritornare,
 
 % In questo caso si è tratterà di illustrare un esempio relativo ad un
 % gestore per che è previsto ritornare,
 
-
 \begin{figure}[!htb]
   \footnotesize 
   \begin{lstlisting}{}
 \begin{figure}[!htb]
   \footnotesize 
   \begin{lstlisting}{}
-#include <errno.h>       /* error symbol definitions */
-#include <signal.h>      /* signal handling declarations */
-#include <sys/types.h>
-#include <sys/wait.h>
-#include "macro.h"
-
 void HandSigCHLD(int sig)
 {
     int errno_save;
 void HandSigCHLD(int sig)
 {
     int errno_save;
@@ -1471,7 +1467,7 @@ rimosso sar
 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
 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 zombie per un tempo indefinito.
+resterebbero in stato di zombie\index{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
 
 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
@@ -1559,8 +1555,8 @@ 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 quest'ultima, cosicché essa sarebbe eseguita dopo
 l'arrivo di \const{SIGALRM}. In questo caso ci si troverebbe di fronte ad un
 capitare (ad esempio se il sistema è molto carico) che il tempo di attesa
 scada prima dell'esecuzione quest'ultima, cosicché essa sarebbe eseguita dopo
 l'arrivo di \const{SIGALRM}. In questo caso ci si troverebbe di fronte ad un
-deadlock, in quanto \func{pause} non verrebbe mai più interrotta (se non in
-caso di un altro segnale).
+deadlock\index{deadlock}, in quanto \func{pause} non verrebbe mai più
+interrotta (se non in caso di un altro segnale).
 
 Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
 SVr2) usando la funzione \func{longjmp} (vedi \secref{sec:proc_longjmp}) per
 
 Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
 SVr2) usando la funzione \func{longjmp} (vedi \secref{sec:proc_longjmp}) per
@@ -1779,10 +1775,10 @@ corrente viene restituito indietro.  Questo permette (specificando \param{act}
 nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
 che non consente di ottenere l'azione corrente senza installarne una nuova.
 
 nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
 che non consente di ottenere l'azione corrente senza installarne una nuova.
 
-Entrambi i puntatori fanno riferimento alla struttura \var{sigaction}, tramite
-la quale si specificano tutte le caratteristiche dell'azione associata ad un
-segnale.  Anch'essa è descritta dallo standard POSIX.1 ed in Linux è definita
-secondo quanto riportato in \figref{fig:sig_sigaction}. Il campo
+Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
+tramite la quale si specificano tutte le caratteristiche dell'azione associata
+ad un segnale.  Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
+definita secondo quanto riportato in \figref{fig:sig_sigaction}. Il campo
 \var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
 più usato.
 
 \var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
 più usato.
 
@@ -1801,7 +1797,7 @@ struct sigaction
     \end{lstlisting}
   \end{minipage} 
   \normalsize 
     \end{lstlisting}
   \end{minipage} 
   \normalsize 
-  \caption{La struttura \var{sigaction}.} 
+  \caption{La struttura \structd{sigaction}.} 
   \label{fig:sig_sigaction}
 \end{figure}
 
   \label{fig:sig_sigaction}
 \end{figure}
 
@@ -1857,7 +1853,7 @@ in \tabref{tab:sig_sa_flag}.
                            \secref{sec:sig_specific_features}).\\ 
     \hline
   \end{tabular}
                            \secref{sec:sig_specific_features}).\\ 
     \hline
   \end{tabular}
-  \caption{Valori del campo \var{sa\_flag} della struttura \var{sigaction}.}
+  \caption{Valori del campo \var{sa\_flag} della struttura \struct{sigaction}.}
   \label{tab:sig_sa_flag}
 \end{table}
 
   \label{tab:sig_sa_flag}
 \end{table}
 
@@ -1866,7 +1862,7 @@ permette\footnote{La possibilit
   stata aggiunta nei kernel della serie 2.1.x con l'introduzione dei segnali
   real-time (vedi \secref{sec:sig_real_time}). In precedenza era possibile
   ottenere alcune informazioni addizionali usando \var{sa\_handler} con un
   stata aggiunta nei kernel della serie 2.1.x con l'introduzione dei segnali
   real-time (vedi \secref{sec:sig_real_time}). In precedenza era possibile
   ottenere alcune informazioni addizionali usando \var{sa\_handler} con un
-  secondo parametro addizionale di tipo \var{struct sigcontext}, che adesso è
+  secondo parametro addizionale di tipo \var{sigcontext}, che adesso è
   deprecato.}  di utilizzare due forme diverse di gestore, da
 specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO},
 rispettivamente attraverso i campi \var{sa\_sigaction} o \var{sa\_handler},
   deprecato.}  di utilizzare due forme diverse di gestore, da
 specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO},
 rispettivamente attraverso i campi \var{sa\_sigaction} o \var{sa\_handler},
@@ -1874,7 +1870,7 @@ rispettivamente attraverso i campi \var{sa\_sigaction} o \var{sa\_handler},
 questi vengono addirittura definiti come \ctyp{union}): la prima è quella
 classica usata anche con \func{signal}, la seconda permette invece di usare un
 gestore in grado di ricevere informazioni più dettagliate dal sistema,
 questi vengono addirittura definiti come \ctyp{union}): la prima è quella
 classica usata anche con \func{signal}, la seconda permette invece di usare un
 gestore in grado di ricevere informazioni più dettagliate dal sistema,
-attraverso la struttura \type{siginfo\_t}, riportata in
+attraverso la struttura \struct{siginfo\_t}, riportata in
 \figref{fig:sig_siginfo_t}.
 
 \begin{figure}[!htb]
 \figref{fig:sig_siginfo_t}.
 
 \begin{figure}[!htb]
@@ -1900,7 +1896,7 @@ siginfo_t {
     \end{lstlisting}
   \end{minipage} 
   \normalsize 
     \end{lstlisting}
   \end{minipage} 
   \normalsize 
-  \caption{La struttura \type{siginfo\_t}.} 
+  \caption{La struttura \structd{siginfo\_t}.} 
   \label{fig:sig_siginfo_t}
 \end{figure}
  
   \label{fig:sig_siginfo_t}
 \end{figure}
  
@@ -1934,14 +1930,14 @@ al processo che ha emesso il segnale, \const{SIGILL}, \const{SIGFPE},
 \const{SIGSEGV} e \const{SIGBUS} avvalorano \var{si\_addr} con l'indirizzo cui
 è avvenuto l'errore, \const{SIGIO} (vedi \secref{sec:file_asyncronous_io})
 avvalora \var{si\_fd} con il numero del file descriptor e \var{si\_band} per i
 \const{SIGSEGV} e \const{SIGBUS} avvalorano \var{si\_addr} con l'indirizzo cui
 è avvenuto l'errore, \const{SIGIO} (vedi \secref{sec:file_asyncronous_io})
 avvalora \var{si\_fd} con il numero del file descriptor e \var{si\_band} per i
-dati urgenti su un socket.
+dati urgenti su un socket\index{socket}.
 
 Benché sia possibile usare nello stesso programma sia \func{sigaction} che
 \func{signal} occorre molta attenzione, in quanto le due funzioni possono
 interagire in maniera anomala. Infatti l'azione specificata con
 
 Benché sia possibile usare nello stesso programma sia \func{sigaction} che
 \func{signal} occorre molta attenzione, in quanto le due funzioni possono
 interagire in maniera anomala. Infatti l'azione specificata con
-\var{sigaction} contiene un maggior numero di informazioni rispetto al
-semplice indirizzo del gestore restituito da \func{signal}.  Per questo
-motivo se si usa quest'ultima per installare un gestore sostituendone uno
+\struct{sigaction} contiene un maggior numero di informazioni rispetto al
+semplice indirizzo del gestore restituito da \func{signal}.  Per questo motivo
+se si usa quest'ultima per installare un gestore sostituendone uno
 precedentemente installato con \func{sigaction}, non sarà possibile effettuare
 un ripristino corretto dello stesso.
 
 precedentemente installato con \func{sigaction}, non sarà possibile effettuare
 un ripristino corretto dello stesso.
 
@@ -1960,17 +1956,15 @@ typedef void SigFunc(int);
 inline SigFunc * Signal(int signo, SigFunc *func) 
 {
     struct sigaction new_handl, old_handl;
 inline SigFunc * Signal(int signo, SigFunc *func) 
 {
     struct sigaction new_handl, old_handl;
-    new_handl.sa_handler=func;
+    new_handl.sa_handler = func;
     /* clear signal mask: no signal blocked during execution of func */
     /* clear signal mask: no signal blocked during execution of func */
-    if (sigemptyset(&new_handl.sa_mask)!=0){  /* initialize signal set */
-        perror("cannot initializes the signal set to empty"); /* see mess. */
-        exit(1);
+    if (sigemptyset(&new_handl.sa_mask)!=0){        /* initialize signal set */
+        return SIG_ERR;
     }
     }
-    new_handl.sa_flags=0;                  /* init to 0 all flags */
+    new_handl.sa_flags=0;                             /* init to 0 all flags */
     /* change action for signo signal */
     /* change action for signo signal */
-    if (sigaction(signo,&new_handl,&old_handl)){ 
-        perror("sigaction failed on signal action setting");
-        exit(1);
+    if (sigaction(signo, &new_handl, &old_handl)){ 
+        return SIG_ERR;
     }
     return (old_handl.sa_handler);
 }
     }
     return (old_handl.sa_handler);
 }
@@ -1982,10 +1976,29 @@ inline SigFunc * Signal(int signo, SigFunc *func)
 \end{figure}
 
 Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
 \end{figure}
 
 Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
-che abbia le stesse caratteristiche di \func{signal}, a definire una funzione
-equivalente attraverso \func{sigaction}; la funzione è \code{Signal}, e si
-trova definita nel file \file{SigHand.c} (nei sorgenti allegati), e riportata
-in \figref{fig:sig_Signal_code}. La riutilizzeremo spesso in seguito.
+che abbia le stesse caratteristiche di \func{signal}, a definire attraverso
+\func{sigaction} una funzione equivalente, il cui codice è riportato in
+\figref{fig:sig_Signal_code} (il codice completo si trova nel file
+\file{SigHand.c} nei sorgenti allegati).  Si noti come, essendo la funzione
+estremamente semplice, è definita come \direct{inline}.\footnote{la direttiva
+  \direct{inline} viene usata per dire al compilatore di trattare la funzione
+  cui essa fa riferimento in maniera speciale inserendo il codice direttamente
+  nel testo del programma.  Anche se i compilatori più moderni sono in grado
+  di effettuare da soli queste manipolazioni (impostando le opportune
+  ottimizzazioni) questa è una tecnica usata per migliorare le prestazioni per
+  le funzioni piccole ed usate di frequente (in particolare nel kernel, dove
+  in certi casi le ottimizzazioni dal compilatore, tarate per l'uso in user
+  space, non sono sempre adatte). In tal caso infatti le istruzioni per creare
+  un nuovo frame nello stack per chiamare la funzione costituirebbero una
+  parte rilevante del codice, appesantendo inutilmente il programma.
+  Originariamente questo comportamento veniva ottenuto con delle macro, ma
+  queste hanno tutta una serie di problemi di sintassi nel passaggio degli
+  argomenti (si veda ad esempio \cite{PratC}) che in questo modo possono
+  essere evitati.}
+
+
+
+
 
 \subsection{La gestione della \textsl{maschera dei segnali} o 
   \textit{signal mask}}
 
 \subsection{La gestione della \textsl{maschera dei segnali} o 
   \textit{signal mask}}
@@ -1996,12 +2009,12 @@ permettono si 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
 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
-  essa è mantenuta dal campo \var{blocked} della \var{task\_struct} del
+  essa è mantenuta dal campo \var{blocked} della \struct{task\_struct} del
   processo.} cioè l'insieme dei segnali la cui consegna è bloccata. Abbiamo
 accennato in \secref{sec:proc_fork} che la \textit{signal mask} viene
 ereditata dal padre alla creazione di un processo figlio, e abbiamo visto al
 paragrafo precedente che essa può essere modificata, durante l'esecuzione di
   processo.} cioè l'insieme dei segnali la cui consegna è bloccata. Abbiamo
 accennato in \secref{sec:proc_fork} che la \textit{signal mask} viene
 ereditata dal padre alla creazione di un processo figlio, e abbiamo visto al
 paragrafo precedente che essa può essere modificata, durante l'esecuzione di
-un gestore, attraverso l'uso dal campo \var{sa\_mask} di \var{sigaction}.
+un gestore, attraverso l'uso dal campo \var{sa\_mask} di \struct{sigaction}.
 
 Uno dei problemi evidenziatisi con l'esempio di \secref{fig:sig_event_wrong} è
 che in molti casi è necessario proteggere delle sezioni di codice (nel caso in
 
 Uno dei problemi evidenziatisi con l'esempio di \secref{fig:sig_event_wrong} è
 che in molti casi è necessario proteggere delle sezioni di codice (nel caso in
@@ -2169,8 +2182,9 @@ segnale, i passi sono sempre i seguenti:
 \item Ripristinare la maschera dei segnali originaria.
 \end{enumerate*}
 Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi
 \item Ripristinare la maschera dei segnali originaria.
 \end{enumerate*}
 Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi
-riabilitarla immediatamente dopo, in questo modo si evita il deadlock dovuto
-all'arrivo del segnale prima dell'esecuzione di \func{sigsuspend}.
+riabilitarla immediatamente dopo, in questo modo si evita il
+deadlock\index{deadlock} dovuto all'arrivo del segnale prima dell'esecuzione
+di \func{sigsuspend}.
 
 
 \subsection{Ulteriori funzioni di gestione}
 
 
 \subsection{Ulteriori funzioni di gestione}
@@ -2265,11 +2279,11 @@ typedef struct {
     \end{lstlisting}
   \end{minipage} 
   \normalsize 
     \end{lstlisting}
   \end{minipage} 
   \normalsize 
-  \caption{La struttura \var{stack\_t}.} 
+  \caption{La struttura \structd{stack\_t}.} 
   \label{fig:sig_stack_t}
 \end{figure}
 
   \label{fig:sig_stack_t}
 \end{figure}
 
-Il campo \var{ss\_sp} di \var{stack\_t} indica l'indirizzo base dello stack,
+Il campo \var{ss\_sp} di \struct{stack\_t} indica l'indirizzo base dello stack,
 mentre \var{ss\_size} ne indica la dimensione; il campo \var{ss\_flags} invece
 indica lo stato dello stack. Nell'indicare un nuovo stack occorre
 inizializzare \var{ss\_sp} e \var{ss\_size} rispettivamente al puntatore e
 mentre \var{ss\_size} ne indica la dimensione; il campo \var{ss\_flags} invece
 indica lo stato dello stack. Nell'indicare un nuovo stack occorre
 inizializzare \var{ss\_sp} e \var{ss\_size} rispettivamente al puntatore e
@@ -2313,16 +2327,16 @@ caratteristiche si sono abilitate con le macro viste in
 \secref{sec:intro_gcc_glibc_std}.
 
 Lo standard POSIX però prevede anche la presenza di altre due funzioni
 \secref{sec:intro_gcc_glibc_std}.
 
 Lo standard POSIX però prevede anche la presenza di altre due funzioni
-\func{sigsetjmp} e \func{siglongjmp}, che permettono di decidere quale dei due
-comportamenti il programma deve assumere; i loro prototipi sono:
+\funcd{sigsetjmp} e \funcd{siglongjmp}, che permettono di decidere quale dei
+due comportamenti il programma deve assumere; i loro prototipi sono:
 \begin{functions}
   \headdecl{setjmp.h} 
   
   \funcdecl{int sigsetjmp(sigjmp\_buf env, int savesigs)} Salva il contesto
 \begin{functions}
   \headdecl{setjmp.h} 
   
   \funcdecl{int sigsetjmp(sigjmp\_buf env, int savesigs)} Salva il contesto
-  dello stack per un salto non locale.
+  dello stack per un salto non-locale\index{salto non-locale}.
  
  
-  \funcdecl{void siglongjmp(sigjmp\_buf env, int val)} Esegue un salto non
-  locale su un precedente contesto.
+  \funcdecl{void siglongjmp(sigjmp\_buf env, int val)} Esegue un salto
+  non-locale su un precedente contesto.
 
   \bodydesc{Le due funzioni sono identiche alle analoghe \func{setjmp} e
     \func{longjmp} di \secref{sec:proc_longjmp}, ma consentono di specificare
 
   \bodydesc{Le due funzioni sono identiche alle analoghe \func{setjmp} e
     \func{longjmp} di \secref{sec:proc_longjmp}, ma consentono di specificare
@@ -2330,10 +2344,11 @@ comportamenti il programma deve assumere; i loro prototipi sono:
 \end{functions}
 
 Le due funzioni prendono come primo argomento la variabile su cui viene
 \end{functions}
 
 Le due funzioni prendono come primo argomento la variabile su cui viene
-salvato il contesto dello stack per permettere il salto non locale; nel caso
-specifico essa è di tipo \type{sigjmp\_buf}, e non \type{jmp\_buf} come per le
-analoghe di \secref{sec:proc_longjmp} in quanto in questo caso viene salvata
-anche la maschera dei segnali.
+salvato il contesto dello stack per permettere il salto non-locale
+\index{salto non-locale}; nel caso specifico essa è di tipo
+\type{sigjmp\_buf}, e non \type{jmp\_buf} come per le analoghe di
+\secref{sec:proc_longjmp} in quanto in questo caso viene salvata anche la
+maschera dei segnali.
 
 Nel caso di \func{sigsetjmp} se si specifica un valore di \param{savesigs}
 diverso da zero la maschera dei valori sarà salvata in \param{env} e
 
 Nel caso di \func{sigsetjmp} se si specifica un valore di \param{savesigs}
 diverso da zero la maschera dei valori sarà salvata in \param{env} e
@@ -2386,7 +2401,7 @@ vengono chiamati \textsl{segnali real-time}, in particolare:
   con un numero minore, che pertanto hanno una priorità maggiore.
 \item è stata introdotta la possibilità di restituire dei dati al
   gestore, attraverso l'uso di un campo apposito nella struttura
   con un numero minore, che pertanto hanno una priorità maggiore.
 \item è stata introdotta la possibilità di restituire dei dati al
   gestore, attraverso l'uso di un campo apposito nella struttura
-  \type{siginfo\_t} accessibile tramite gestori di tipo
+  \struct{siginfo\_t} accessibile tramite gestori di tipo
   \var{sa\_sigaction}.
 \end{itemize*}
 
   \var{sa\_sigaction}.
 \end{itemize*}
 
@@ -2409,9 +2424,9 @@ real-time.
 Si tenga presente che questi nuovi segnali non sono associati a nessun evento
 sepcifico (a meno di non utilizzarli, come vedremo in
 \secref{sec:file_asyncronous_io}, per l'I/O asincrono) e devono essere inviati
 Si tenga presente che questi nuovi segnali non sono associati a nessun evento
 sepcifico (a meno di non utilizzarli, come vedremo in
 \secref{sec:file_asyncronous_io}, per l'I/O asincrono) e devono essere inviati
-esplicitamente. Tutti i segnali real-time restituiscono al gestore, oltre
-ai campi \var{si\_pid} e \var{si\_uid} di \type{siginfo\_t} una struttura
-\type{sigval} (riportata in \figref{fig:sig_sigval}) in cui può essere
+esplicitamente. Tutti i segnali real-time restituiscono al gestore, oltre ai
+campi \var{si\_pid} e \var{si\_uid} di \struct{siginfo\_t} una struttura
+\struct{sigval} (riportata in \figref{fig:sig_sigval}) in cui può essere
 restituito al processo un valore o un indirizzo, che costituisce il meccanismo
 con cui il segnale è in grado di inviare una ulteriore informazione al
 processo.
 restituito al processo un valore o un indirizzo, che costituisce il meccanismo
 con cui il segnale è in grado di inviare una ulteriore informazione al
 processo.
@@ -2427,15 +2442,15 @@ union sigval {
     \end{lstlisting}
   \end{minipage} 
   \normalsize 
     \end{lstlisting}
   \end{minipage} 
   \normalsize 
-  \caption{La struttura \type{sigval}, usata dai segnali real time per
+  \caption{La struttura \structd{sigval}, usata dai segnali real time per
     restituire dati al gestore.}
   \label{fig:sig_sigval}
 \end{figure}
 
 A causa di queste loro caratteristiche, la funzione \func{kill} non è adatta
 ad inviare un segnale real time, in quanto non è in grado di fornire alcun
     restituire dati al gestore.}
   \label{fig:sig_sigval}
 \end{figure}
 
 A causa di queste loro caratteristiche, la funzione \func{kill} non è adatta
 ad inviare un segnale real time, in quanto non è in grado di fornire alcun
-valore per \var{sigval}; per questo motivo lo standard ha previsto una nuova
-funzione, \func{sigqueue}, il cui prototipo è:
+valore per \struct{sigval}; per questo motivo lo standard ha previsto una
+nuova funzione, \func{sigqueue}, il cui prototipo è:
 \begin{prototype}{signal.h}
   {int sigqueue(pid\_t pid, int signo, const union sigval value)}
   
 \begin{prototype}{signal.h}
   {int sigqueue(pid\_t pid, int signo, const union sigval value)}
   
@@ -2462,17 +2477,17 @@ stessi; un valore nullo di \func{signo} permette di verificare le condizioni
 di errore senza inviare nessun segnale.
 
 Se il segnale è bloccato la funzione ritorna immediatamente, se si è
 di errore senza inviare nessun segnale.
 
 Se il segnale è bloccato la funzione ritorna immediatamente, se si è
-installato un gestore con \const{SA\_SIGINFO} e ci sono risorse
-disponibili, vale a dire che c'è posto nella coda\footnote{la profondità della
-  coda è indicata dalla costante \const{SIGQUEUE\_MAX}, una della tante
-  costanti di sistema definite dallo standard POSIX, che non abbiamo riportato
+installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili,
+vale a dire che c'è posto nella coda\footnote{la profondità della coda è
+  indicata dalla costante \const{SIGQUEUE\_MAX}, una della tante costanti di
+  sistema definite dallo standard POSIX, che non abbiamo riportato
   esplicitamente in \secref{sec:sys_limits}. Il suo valore minimo secondo lo
   standard, \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32.}, esso viene inserito
 e diventa pendente; una volta consegnato riporterà nel campo \var{si\_code} di
   esplicitamente in \secref{sec:sys_limits}. Il suo valore minimo secondo lo
   standard, \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32.}, esso viene inserito
 e diventa pendente; una volta consegnato riporterà nel campo \var{si\_code} di
-\var{siginfo} il valore \const{SI\_QUEUE} e il campo \var{si\_value} riceverà
-quanto inviato con \param{value}. Se invece si è installato un gestore
-nella forma classica il segnale sarà generato, ma tutte le caratteristiche
-tipiche dei segnali real-time (priorità e coda) saranno perse.
+\struct{siginfo} il valore \const{SI\_QUEUE} e il campo \var{si\_value}
+riceverà quanto inviato con \param{value}. Se invece si è installato un
+gestore nella forma classica il segnale sarà generato, ma tutte le
+caratteristiche tipiche dei segnali real-time (priorità e coda) saranno perse.
 
 Lo standard POSIX.1b definisce inoltre delle nuove funzioni che permettono di
 gestire l'attesa di segnali specifici su una coda, esse servono in particolar
 
 Lo standard POSIX.1b definisce inoltre delle nuove funzioni che permettono di
 gestire l'attesa di segnali specifici su una coda, esse servono in particolar