Riordinamento completo degli indici. Create della macro ad hoc per la

[gapil.git] / signal.tex

diff --git a/signal.tex b/signal.tex
index 1288d6c95b6168cee4c0da69afe6d85120b97454..0c11317cdd11ffe81b69a6fec60c657b2e9f2581 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -116,7 +116,7 @@ verr
 Questa è la ragione per cui l'implementazione dei segnali secondo questa
 semantica viene chiamata \textsl{inaffidabile}; infatti la ricezione del
 segnale e la reinstallazione del suo gestore non sono operazioni atomiche, e
 Questa è la ragione per cui l'implementazione dei segnali secondo questa
 semantica viene chiamata \textsl{inaffidabile}; infatti la ricezione del
 segnale e la reinstallazione del suo gestore non sono operazioni atomiche, e

-sono sempre possibili delle race condition\index{\textit{race~condition}}
+sono sempre possibili delle \textit{race condition}\itindex{race~condition}

 (sull'argomento vedi quanto detto in sez.~\ref{sec:proc_multi_prog}).
 
 Un altro problema è che in questa semantica non esiste un modo per bloccare i
 (sull'argomento vedi quanto detto in sez.~\ref{sec:proc_multi_prog}).
 
 Un altro problema è che in questa semantica non esiste un modo per bloccare i


@@ -136,7 +136,7 @@ Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
 \textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
 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
 \textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
 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{\textit{scheduler}} quando,
+procedura viene effettuata dallo scheduler\itindex{scheduler} quando,

 riprendendo l'esecuzione del processo in questione, verifica la presenza del
 segnale nella \struct{task\_struct} e mette in esecuzione il gestore.
 
 riprendendo l'esecuzione del processo in questione, verifica la presenza del
 segnale nella \struct{task\_struct} e mette in esecuzione il gestore.
 


@@ -209,9 +209,9 @@ ignorarlo).
 
 Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
 avviene non appena questo viene rimesso in esecuzione dallo
 
 Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
 avviene non appena questo viene rimesso in esecuzione dallo

-scheduler\index{\textit{scheduler}} che esegue l'azione specificata. Questo a
-meno che il segnale in questione non sia stato bloccato prima della notifica,
-nel qual caso l'invio non avviene ed il segnale resta \textsl{pendente}
+scheduler\itindex{scheduler} che esegue l'azione specificata. Questo a meno
+che il segnale in questione non sia stato bloccato prima della notifica, nel
+qual caso l'invio non avviene ed il segnale resta \textsl{pendente}

 indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
 notificato. Si tenga presente però che i segnali \textsl{pendenti} non si
 accodano, alla generazione infatti il kernel marca un flag nella
 indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
 notificato. Si tenga presente però che i segnali \textsl{pendenti} non si
 accodano, alla generazione infatti il kernel marca un flag nella


@@ -241,11 +241,11 @@ una  delle tre possibilit
 
 Un programma può specificare queste scelte usando le due funzioni
 \func{signal} e \func{sigaction} (vedi sez.~\ref{sec:sig_signal} e
 
 Un programma può specificare queste scelte usando le due funzioni
 \func{signal} e \func{sigaction} (vedi sez.~\ref{sec:sig_signal} e

-sez.~\ref{sec:sig_sigaction}). Se si è installato un gestore sarà
-quest'ultimo ad essere eseguito alla notifica del segnale.  Inoltre il sistema
-farà si che mentre viene eseguito il gestore di un segnale, quest'ultimo
-venga automaticamente bloccato (così si possono evitare race
-condition\index{\textit{race~condition}}).
+sez.~\ref{sec:sig_sigaction}). Se si è installato un gestore sarà quest'ultimo
+ad essere eseguito alla notifica del segnale.  Inoltre il sistema farà si che
+mentre viene eseguito il gestore di un segnale, quest'ultimo venga
+automaticamente bloccato (così si possono evitare \textit{race
+  condition}\itindex{race~condition}).

 
 Nel caso non sia stata specificata un'azione, viene utilizzata l'azione
 standard che (come vedremo in sez.~\ref{sec:sig_standard}) è propria di ciascun
 
 Nel caso non sia stata specificata un'azione, viene utilizzata l'azione
 standard che (come vedremo in sez.~\ref{sec:sig_standard}) è propria di ciascun


@@ -279,7 +279,7 @@ di identificarli, e le funzioni che ne stampano la descrizione.
 
 Ciascun segnale è identificato rispetto al sistema da un numero, ma l'uso
 diretto di questo numero da parte dei programmi è da evitare, in quanto esso
 
 Ciascun segnale è identificato rispetto al sistema da un numero, ma l'uso
 diretto di questo numero da parte dei programmi è da evitare, in quanto esso

-può variare a seconda dell'implementazione del sistema, e nel caso si Linux,
+può variare a seconda dell'implementazione del sistema, e nel caso di Linux,

 anche a seconda dell'architettura hardware. 
 Per questo motivo ad ogni segnale viene associato un nome, definendo con una
 macro di preprocessore una costante uguale al suddetto numero. Sono questi
 anche a seconda dell'architettura hardware. 
 Per questo motivo ad ogni segnale viene associato un nome, definendo con una
 macro di preprocessore una costante uguale al suddetto numero. Sono questi


@@ -415,11 +415,11 @@ tipologia, verr
 \label{sec:sig_prog_error}
 
 Questi segnali sono generati quando il sistema, o in certi casi direttamente
 \label{sec:sig_prog_error}
 
 Questi segnali sono generati quando il sistema, o in certi casi direttamente

-l'hardware (come per i \textit{page fault} non validi) rileva un qualche
-errore insanabile nel programma in esecuzione. In generale la generazione di
-questi segnali significa che il programma ha dei gravi problemi (ad esempio ha
-dereferenziato un puntatore non valido o ha eseguito una operazione aritmetica
-proibita) e l'esecuzione non può essere proseguita.
+l'hardware (come per i \itindex{page~fault}\textit{page fault} non validi)
+rileva un qualche errore insanabile nel programma in esecuzione. In generale
+la generazione di questi segnali significa che il programma ha dei gravi
+problemi (ad esempio ha dereferenziato un puntatore non valido o ha eseguito
+una operazione aritmetica proibita) e l'esecuzione non può essere proseguita.

 
 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


@@ -512,8 +512,8 @@ segnali sono:
   interruzione per il programma. È quello che viene generato di default dal
   comando \cmd{kill} o dall'invio sul terminale del carattere di controllo
   INTR (interrupt, generato dalla sequenza \cmd{C-c}).
   interruzione per il programma. È quello che viene generato di default dal
   comando \cmd{kill} o dall'invio sul terminale del carattere di controllo
   INTR (interrupt, generato dalla sequenza \cmd{C-c}).

-\item[\const{SIGQUIT}] È analogo a \const{SIGINT} con la differenze che è
-  controllato da un'altro carattere di controllo, QUIT, corrispondente alla
+\item[\const{SIGQUIT}] È analogo a \const{SIGINT} con la differenza che è
+  controllato da un altro carattere di controllo, QUIT, corrispondente alla

   sequenza \verb|C-\|. A differenza del precedente l'azione predefinita, oltre
   alla terminazione del processo, comporta anche la creazione di un core dump.
 
   sequenza \verb|C-\|. A differenza del precedente l'azione predefinita, oltre
   alla terminazione del processo, comporta anche la creazione di un core dump.
 


@@ -890,9 +890,9 @@ Il numero di segnale passato in \param{signum} pu
 direttamente con una delle costanti definite in sez.~\ref{sec:sig_standard}. Il
 gestore \param{handler} invece, oltre all'indirizzo della funzione da chiamare
 all'occorrenza del segnale, può assumere anche i due valori costanti
 direttamente con una delle costanti definite in sez.~\ref{sec:sig_standard}. Il
 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
+\const{SIG\_IGN} con cui si dice di ignorare il segnale e \const{SIG\_DFL} per

 reinstallare l'azione predefinita.\footnote{si ricordi però che i due segnali
 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.}
 
   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
 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 e 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
 
 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


@@ -1113,7 +1112,7 @@ suo prototipo 
     itimerval *value, struct itimerval *ovalue)} 
   
   Predispone l'invio di un segnale di allarme alla scadenza dell'intervallo
     itimerval *value, struct itimerval *ovalue)} 
   
   Predispone l'invio di un segnale di allarme alla scadenza dell'intervallo

-  \param{value} sul timer specificato da \func{which}.
+  \param{value} sul timer specificato da \param{which}.

   
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
     errore, nel qual caso \var{errno} assumerà uno dei valori \errval{EINVAL} o
   
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
     errore, nel qual caso \var{errno} assumerà uno dei valori \errval{EINVAL} o


@@ -1209,7 +1208,7 @@ valore corrente di un timer senza modificarlo, 
 \begin{prototype}{sys/time.h}{int getitimer(int which, struct
     itimerval *value)}
   
 \begin{prototype}{sys/time.h}{int getitimer(int which, struct
     itimerval *value)}
   

-  Legge in \param{value} il valore del timer specificato da \func{which}.
+  Legge in \param{value} il valore del timer specificato da \param{which}.

   
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
     errore e restituisce gli stessi errori di \func{getitimer}}
   
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
     errore e restituisce gli stessi errori di \func{getitimer}}


@@ -1241,7 +1240,7 @@ il processo non viene terminato direttamente dal gestore sia la stessa
 \func{abort} a farlo al ritorno dello stesso. Inoltre, sempre seguendo lo
 standard POSIX, prima della terminazione tutti i file aperti e gli stream
 saranno chiusi ed i buffer scaricati su disco. Non verranno invece eseguite le
 \func{abort} a farlo al ritorno dello stesso. Inoltre, sempre seguendo lo
 standard POSIX, prima della terminazione tutti i file aperti e gli stream
 saranno chiusi ed i buffer scaricati su disco. Non verranno invece eseguite le

-eventuali funzioni registrate con \func{at\_exit} e \func{on\_exit}.
+eventuali funzioni registrate con \func{atexit} e \func{on\_exit}.

 
 
 \subsection{Le funzioni di pausa e attesa}
 
 
 \subsection{Le funzioni di pausa e attesa}


@@ -1355,15 +1354,14 @@ Chiaramente, anche se il tempo pu
 nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
 temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
 specificato, ma prima che il processo possa tornare ad essere eseguito
 nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
 temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
 specificato, ma prima che il processo possa tornare ad essere eseguito

-occorrerà almeno attendere il successivo giro di
-scheduler\index{\textit{scheduler}} e cioè un tempo che a seconda dei casi può
-arrivare fino a 1/\const{HZ}, (sempre che il sistema sia scarico ed il
-processa venga immediatamente rimesso in esecuzione); per questo motivo il
-valore restituito in \param{rem} è sempre arrotondato al multiplo successivo
-di 1/\const{HZ}.
+occorrerà almeno attendere il successivo giro di scheduler\itindex{scheduler}
+e cioè un tempo che a seconda dei casi può arrivare fino a 1/\const{HZ},
+(sempre che il sistema sia scarico ed il processa venga immediatamente rimesso
+in esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
+arrotondato al multiplo successivo di 1/\const{HZ}.

 
 In realtà è possibile ottenere anche pause più precise del centesimo di
 
 In realtà è possibile ottenere anche pause più precise del centesimo di

-secondo usando politiche di scheduling real time come \const{SCHED\_FIFO} o
+secondo usando politiche di scheduling real-time come \const{SCHED\_FIFO} o

 \const{SCHED\_RR}; in tal caso infatti il meccanismo di scheduling ordinario
 viene evitato, e si raggiungono pause fino ai 2~ms con precisioni del $\mu$s.
 
 \const{SCHED\_RR}; in tal caso infatti il meccanismo di scheduling ordinario
 viene evitato, e si raggiungono pause fino ai 2~ms con precisioni del $\mu$s.
 


@@ -1398,12 +1396,6 @@ di sez.~\ref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione
 gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione
 di zombie\index{zombie}.
 
 gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione
 di zombie\index{zombie}.
 

-%  è pertanto
-% naturale usare un esempio che ci permette di concludere la trattazione della
-% terminazione dei processi.
-% In questo caso si è tratterà di illustrare un esempio relativo ad un
-% gestore per che è previsto ritornare,
-

 \begin{figure}[!htb]
   \footnotesize  \centering
   \begin{minipage}[c]{15cm}
 \begin{figure}[!htb]
   \footnotesize  \centering
   \begin{minipage}[c]{15cm}


@@ -1411,7 +1403,7 @@ di zombie\index{zombie}.
   \end{minipage}
   \normalsize 
   \caption{Codice di una funzione generica di gestione per il segnale
   \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}
 
   \label{fig:sig_sigchld_handl}
 \end{figure}
 


@@ -1421,7 +1413,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
 \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
 
 Il compito principale del gestore è quello di ricevere lo stato di
 terminazione del processo, cosa che viene eseguita nel ciclo in


@@ -1437,7 +1429,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à
 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
 
 Allora, nel caso della terminazione dei processi figli, se si chiamasse
 \func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un


@@ -1458,8 +1450,8 @@ tutti gli stati di terminazione sono stati ricevuti.
 
 Le funzioni esaminate finora fanno riferimento alle modalità più elementari
 della gestione dei segnali; non si sono pertanto ancora prese in
 
 Le funzioni esaminate finora fanno riferimento alle modalità più elementari
 della gestione dei segnali; non si sono pertanto ancora prese in

-considerazione le tematiche più complesse, collegate alle varie race
-condition\index{\textit{race~condition}} che i segnali possono generare e alla
+considerazione le tematiche più complesse, collegate alle varie \textit{race
+  condition}\itindex{race~condition} che i segnali possono generare e alla

 natura asincrona degli stessi.
 
 Affronteremo queste problematiche in questa sezione, partendo da un esempio
 natura asincrona degli stessi.
 
 Affronteremo queste problematiche in questa sezione, partendo da un esempio


@@ -1501,14 +1493,13 @@ 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à),
 
 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
-tempo di attesa scada prima dell'esecuzione quest'ultima, cosicché essa
+presenta una pericolosa \textit{race condition}\itindex{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
+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
 sarebbe eseguita dopo l'arrivo di \const{SIGALRM}. In questo caso ci si

-troverebbe di fronte ad un deadlock\index{\textit{deadlock}}, in quanto
-\func{pause} non verrebbe mai più interrotta (se non in caso di un altro
-segnale).
+troverebbe di fronte ad un deadlock\itindex{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 sez.~\ref{sec:proc_longjmp}) per
 
 Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
 SVr2) usando la funzione \func{longjmp} (vedi sez.~\ref{sec:proc_longjmp}) per


@@ -1526,8 +1517,8 @@ codice del tipo di quello riportato in fig.~\ref{fig:sig_sleep_incomplete}.
   \label{fig:sig_sleep_incomplete}
 \end{figure}
 
   \label{fig:sig_sleep_incomplete}
 \end{figure}
 

-In questo caso il gestore (\texttt{\small 18-26}) non ritorna come in
-fig.~\ref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 24}) per
+In questo caso il gestore (\texttt{\small 18-27}) non ritorna come in
+fig.~\ref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 25}) per

 rientrare nel corpo principale del programma; dato che in questo caso il
 valore di uscita di \func{setjmp} è 1, grazie alla condizione in
 (\texttt{\small 9-12}) si evita comunque che \func{pause} sia chiamata a
 rientrare nel corpo principale del programma; dato che in questo caso il
 valore di uscita di \func{setjmp} è 1, grazie alla condizione in
 (\texttt{\small 9-12}) si evita comunque che \func{pause} sia chiamata a


@@ -1564,10 +1555,12 @@ quale potr
 segnale, e prendere le relative azioni conseguenti (\texttt{\small 6-11}).
 
 Questo è il tipico esempio di caso, già citato in
 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 race condition
-\index{\textit{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.
+sez.~\ref{sec:proc_race_cond}, in cui si genera una
+\itindex{race~condition}\textit{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
 
 Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono
 funzioni più sofisticate di quelle illustrate finora, che hanno origine dalla


@@ -1580,30 +1573,30 @@ reagire alla ricezione di un segnale.
 \subsection{Gli \textsl{insiemi di segnali} o \textit{signal set}}
 \label{sec:sig_sigset}
 
 \subsection{Gli \textsl{insiemi di segnali} o \textit{signal set}}
 \label{sec:sig_sigset}
 

-\index{\textit{signal~set}|(}
+\itindbeg{signal~set} 
+

 Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali
 originarie, nate con la semantica inaffidabile, hanno dei limiti non
 superabili; in particolare non è prevista nessuna funzione che permetta di
 Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali
 originarie, nate con la semantica inaffidabile, hanno dei limiti non
 superabili; in particolare non è prevista nessuna funzione che permetta di

-gestire gestire il blocco dei segnali o di verificare lo stato dei segnali
-pendenti.  Per questo motivo lo standard POSIX.1, insieme alla nuova semantica
-dei segnali ha introdotto una interfaccia di gestione completamente nuova, che
-permette di ottenete un controllo molto più dettagliato. In particolare lo
+gestire il blocco dei segnali o di verificare lo stato dei segnali pendenti.
+Per questo motivo lo standard POSIX.1, insieme alla nuova semantica dei
+segnali ha introdotto una interfaccia di gestione completamente nuova, che
+permette di ottenere un controllo molto più dettagliato. In particolare lo

 standard ha introdotto un nuovo tipo di dato \type{sigset\_t}, che permette di
 rappresentare un \textsl{insieme di segnali} (un \textit{signal set}, come
 standard ha introdotto un nuovo tipo di dato \type{sigset\_t}, che permette di
 rappresentare un \textsl{insieme di segnali} (un \textit{signal set}, come

-viene usualmente chiamato), che è il tipo di dato che viene usato per gestire
-il blocco dei segnali.
+viene usualmente chiamato), tale tipo di dato viene usato per gestire il
+blocco dei segnali.

 
 In genere un \textsl{insieme di segnali} è rappresentato da un intero di
 
 In genere un \textsl{insieme di segnali} è rappresentato da un intero di

-dimensione opportuna, di solito si pari al numero di bit dell'architettura
-della macchina\footnote{nel caso dei PC questo comporta un massimo di 32
-  segnali distinti, dato che in Linux questi sono sufficienti non c'è
-  necessità di nessuna struttura più complicata.}, ciascun bit del quale è
-associato ad uno specifico segnale; in questo modo è di solito possibile
-implementare le operazioni direttamente con istruzioni elementari del
-processore; lo standard POSIX.1 definisce cinque funzioni per la manipolazione
-degli insiemi di segnali: \funcd{sigemptyset}, \funcd{sigfillset},
-\funcd{sigaddset}, \funcd{sigdelset} e \funcd{sigismember}, i cui prototipi
-sono:
+dimensione opportuna, di solito pari al numero di bit dell'architettura della
+macchina,\footnote{nel caso dei PC questo comporta un massimo di 32 segnali
+  distinti: dato che in Linux questi sono sufficienti non c'è necessità di
+  nessuna struttura più complicata.} ciascun bit del quale è associato ad uno
+specifico segnale; in questo modo è di solito possibile implementare le
+operazioni direttamente con istruzioni elementari del processore. Lo standard
+POSIX.1 definisce cinque funzioni per la manipolazione degli insiemi di
+segnali: \funcd{sigemptyset}, \funcd{sigfillset}, \funcd{sigaddset},
+\funcd{sigdelset} e \funcd{sigismember}, i cui prototipi sono:

 \begin{functions}
   \headdecl{signal.h} 
   
 \begin{functions}
   \headdecl{signal.h} 
   


@@ -1643,8 +1636,8 @@ ottenuto con \func{sigemptyset} o togliendo quelli che non servono da un
 insieme completo ottenuto con \func{sigfillset}. Infine \func{sigismember}
 permette di verificare la presenza di uno specifico segnale in un
 insieme.
 insieme completo ottenuto con \func{sigfillset}. Infine \func{sigismember}
 permette di verificare la presenza di uno specifico segnale in un
 insieme.

-\index{\textit{signal~set}|)}

 
 

+\itindend{signal~set} 

 
 
 \subsection{La funzione \func{sigaction}}
 
 
 \subsection{La funzione \func{sigaction}}


@@ -1656,7 +1649,7 @@ POSIX.1 ha ridefinito completamente l'interfaccia per la gestione dei segnali,
 rendendola molto più flessibile e robusta, anche se leggermente più complessa.
 
 La funzione principale dell'interfaccia POSIX.1 per i segnali è
 rendendola molto più flessibile e robusta, anche se leggermente più complessa.
 
 La funzione principale dell'interfaccia POSIX.1 per i segnali è

-\funcd{sigaction}. Essa ha sostanzialemente lo stesso uso di \func{signal},
+\funcd{sigaction}. Essa ha sostanzialmente lo stesso uso di \func{signal},

 permette cioè di specificare le modalità con cui un segnale può essere gestito
 da un processo. Il suo prototipo è:
 \begin{prototype}{signal.h}{int sigaction(int signum, const struct sigaction
 permette cioè di specificare le modalità con cui un segnale può essere gestito
 da un processo. Il suo prototipo è:
 \begin{prototype}{signal.h}{int sigaction(int signum, const struct sigaction


@@ -1816,10 +1809,11 @@ eventualmente presenti dipendono dal segnale, cos
 segnali real-time (vedi sez.~\ref{sec:sig_real_time}) inviati tramite
 \func{kill} avvalorano \var{si\_pid} e \var{si\_uid} coi valori corrispondenti
 al processo che ha emesso il segnale, \const{SIGILL}, \const{SIGFPE},
 segnali real-time (vedi sez.~\ref{sec:sig_real_time}) inviati tramite
 \func{kill} avvalorano \var{si\_pid} e \var{si\_uid} coi valori corrispondenti
 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 sez.~\ref{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\index{socket}.
+\const{SIGSEGV} e \const{SIGBUS} avvalorano \var{si\_addr} con l'indirizzo in
+cui è avvenuto l'errore, \const{SIGIO} (vedi
+sez.~\ref{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\index{socket}.

 
 Benché sia possibile usare nello stesso programma sia \func{sigaction} che
 \func{signal} occorre molta attenzione, in quanto le due funzioni possono
 
 Benché sia possibile usare nello stesso programma sia \func{sigaction} che
 \func{signal} occorre molta attenzione, in quanto le due funzioni possono


@@ -1844,7 +1838,7 @@ sempre il caso di evitare l'uso di \func{signal} a favore di \func{sigaction}.
     \includecodesample{listati/Signal.c}
   \end{minipage} 
   \normalsize 
     \includecodesample{listati/Signal.c}
   \end{minipage} 
   \normalsize 

-  \caption{La funzione \funcd{Signal}, equivalente a \func{signal}, definita
+  \caption{La funzione \func{Signal}, equivalente a \func{signal}, definita

     attraverso \func{sigaction}.}
   \label{fig:sig_Signal_code}
 \end{figure}
     attraverso \func{sigaction}.}
   \label{fig:sig_Signal_code}
 \end{figure}


@@ -1872,15 +1866,13 @@ estremamente semplice, 
 
 
 
 
 
 

-
-

 \subsection{La gestione della \textsl{maschera dei segnali} o 
   \textit{signal mask}}
 \label{sec:sig_sigmask}
 
 \subsection{La gestione della \textsl{maschera dei segnali} o 
   \textit{signal mask}}
 \label{sec:sig_sigmask}
 

-\index{\textit{signal mask}|(}
+\itindbeg{signal~mask}

 Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like
 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
 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


@@ -1895,7 +1887,7 @@ Uno dei problemi evidenziatisi con l'esempio di fig.~\ref{fig:sig_event_wrong}
 è che in molti casi è necessario proteggere delle sezioni di codice (nel caso
 in questione la sezione fra il controllo e la eventuale cancellazione del flag
 che testimoniava l'avvenuta occorrenza del segnale) in modo da essere sicuri
 è che in molti casi è necessario proteggere delle sezioni di codice (nel caso
 in questione la sezione fra il controllo e la eventuale cancellazione del flag
 che testimoniava l'avvenuta occorrenza del segnale) in modo da essere sicuri

-che essi siano eseguiti senza interruzioni.
+che essi siano eseguite senza interruzioni.

 
 Le operazioni più semplici, come l'assegnazione o il controllo di una
 variabile (per essere sicuri si può usare il tipo \type{sig\_atomic\_t}) di
 
 Le operazioni più semplici, come l'assegnazione o il controllo di una
 variabile (per essere sicuri si può usare il tipo \type{sig\_atomic\_t}) di


@@ -1956,7 +1948,7 @@ occorre ricordare che qualunque modifica alla maschera dei segnali viene
 perduta alla conclusione del terminatore. 
 
 Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
 perduta alla conclusione del terminatore. 
 
 Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte

-dei casi di race condition\index{\textit{race~condition}} restano aperte
+dei casi di \textit{race condition}\itindex{race~condition} restano aperte

 alcune possibilità legate all'uso di \func{pause}; il caso è simile a quello
 del problema illustrato nell'esempio di fig.~\ref{fig:sig_sleep_incomplete}, e
 cioè la possibilità che il processo riceva il segnale che si intende usare per
 alcune possibilità legate all'uso di \func{pause}; il caso è simile a quello
 del problema illustrato nell'esempio di fig.~\ref{fig:sig_sleep_incomplete}, e
 cioè la possibilità che il processo riceva il segnale che si intende usare per


@@ -2000,39 +1992,40 @@ presenta neanche questa necessit
 
 Per evitare i problemi di interferenza con gli altri segnali in questo caso
 non si è usato l'approccio di fig.~\ref{fig:sig_sleep_incomplete} evitando
 
 Per evitare i problemi di interferenza con gli altri segnali in questo caso
 non si è usato l'approccio di fig.~\ref{fig:sig_sleep_incomplete} evitando

-l'uso di \func{longjmp}. Come in precedenza il gestore (\texttt{\small 35-37})
+l'uso di \func{longjmp}. Come in precedenza il gestore (\texttt{\small 27-30})

 non esegue nessuna operazione, limitandosi a ritornare per interrompere il
 programma messo in attesa.
 
 non esegue nessuna operazione, limitandosi a ritornare per interrompere il
 programma messo in attesa.
 

-La prima parte della funzione (\texttt{\small 11-15}) provvede ad installare
+La prima parte della funzione (\texttt{\small 6-10}) provvede ad installare

 l'opportuno gestore per \const{SIGALRM}, salvando quello originario, che
 l'opportuno gestore per \const{SIGALRM}, salvando quello originario, che

-sarà ripristinato alla conclusione della stessa (\texttt{\small 28}); il passo
-successivo è quello di bloccare \const{SIGALRM} (\texttt{\small 17-19}) per
+sarà ripristinato alla conclusione della stessa (\texttt{\small 23}); il passo
+successivo è quello di bloccare \const{SIGALRM} (\texttt{\small 11-14}) per

 evitare che esso possa essere ricevuto dal processo fra l'esecuzione di
 evitare che esso possa essere ricevuto dal processo fra l'esecuzione di

-\func{alarm} (\texttt{\small 21}) e la sospensione dello stesso. Nel fare
+\func{alarm} (\texttt{\small 16}) e la sospensione dello stesso. Nel fare

 questo si salva la maschera corrente dei segnali, che sarà ripristinata alla
 questo si salva la maschera corrente dei segnali, che sarà ripristinata alla

-fine (\texttt{\small 27}), e al contempo si prepara la maschera dei segnali
+fine (\texttt{\small 22}), e al contempo si prepara la maschera dei segnali

 \var{sleep\_mask} per riattivare \const{SIGALRM} all'esecuzione di
 \func{sigsuspend}.  
 
 \var{sleep\_mask} per riattivare \const{SIGALRM} all'esecuzione di
 \func{sigsuspend}.  
 

-In questo modo non sono più possibili race
-condition\index{\textit{race~condition}} dato che \const{SIGALRM} viene
+In questo modo non sono più possibili \textit{race
+  condition}\itindex{race~condition} dato che \const{SIGALRM} viene

 disabilitato con \func{sigprocmask} fino alla chiamata di \func{sigsuspend}.
 Questo metodo è assolutamente generale e può essere applicato a qualunque
 altra situazione in cui si deve attendere per un segnale, i passi sono sempre
 i seguenti:
 \begin{enumerate*}
 \item Leggere la maschera dei segnali corrente e bloccare il segnale voluto
 disabilitato con \func{sigprocmask} fino alla chiamata di \func{sigsuspend}.
 Questo metodo è assolutamente generale e può essere applicato a qualunque
 altra situazione in cui si deve attendere per un segnale, i passi sono sempre
 i seguenti:
 \begin{enumerate*}
 \item Leggere la maschera dei segnali corrente e bloccare il segnale voluto

-  con \func{sigprocmask}. 
+  con \func{sigprocmask};

 \item Mandare il processo in attesa con \func{sigsuspend} abilitando la
 \item Mandare il processo in attesa con \func{sigsuspend} abilitando la

-  ricezione del segnale voluto.
+  ricezione del segnale voluto;

 \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
 \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\index{\textit{deadlock}} dovuto all'arrivo del segnale prima
-dell'esecuzione di \func{sigsuspend}.
-\index{\textit{signal mask}|)}
+deadlock\itindex{deadlock} dovuto all'arrivo del segnale prima dell'esecuzione
+di \func{sigsuspend}.  
+
+\itindend{signal~mask}

 
 
 \subsection{Ulteriori funzioni di gestione}
 
 
 \subsection{Ulteriori funzioni di gestione}


@@ -2054,7 +2047,7 @@ Scrive in \param{set} l'insieme dei segnali pendenti.
 \end{prototype}
 
 La funzione permette di ricavare quali sono i segnali pendenti per il processo
 \end{prototype}
 
 La funzione permette di ricavare quali sono i segnali pendenti per il processo

-in corso, cioè i segnali che sono stato inviati dal kernel ma non sono stati
+in corso, cioè i segnali che sono stati inviati dal kernel ma non sono stati

 ancora ricevuti dal processo in quanto bloccati. Non esiste una funzione
 equivalente nella vecchia interfaccia, ma essa è tutto sommato poco utile,
 dato che essa può solo assicurare che un segnale è stato inviato, dato che
 ancora ricevuti dal processo in quanto bloccati. Non esiste una funzione
 equivalente nella vecchia interfaccia, ma essa è tutto sommato poco utile,
 dato che essa può solo assicurare che un segnale è stato inviato, dato che


@@ -2069,9 +2062,9 @@ gestore. L'uso di uno stack alternativo 
 gestori, occorre però seguire una certa procedura:
 \begin{enumerate}
 \item Allocare un'area di memoria di dimensione sufficiente da usare come
 gestori, occorre però seguire una certa procedura:
 \begin{enumerate}
 \item Allocare un'area di memoria di dimensione sufficiente da usare come

-  stack alternativo.
+  stack alternativo;

 \item Usare la funzione \func{sigaltstack} per rendere noto al sistema
 \item Usare la funzione \func{sigaltstack} per rendere noto al sistema

-  l'esistenza e la locazione dello stack alternativo.
+  l'esistenza e la locazione dello stack alternativo;

 \item Quando si installa un gestore occorre usare \func{sigaction}
   specificando il flag \const{SA\_ONSTACK} (vedi tab.~\ref{tab:sig_sa_flag})
   per dire al sistema di usare lo stack alternativo durante l'esecuzione del
 \item Quando si installa un gestore occorre usare \func{sigaction}
   specificando il flag \const{SA\_ONSTACK} (vedi tab.~\ref{tab:sig_sa_flag})
   per dire al sistema di usare lo stack alternativo durante l'esecuzione del


@@ -2091,7 +2084,7 @@ maggiore di questo valore. Quando si conosce esattamente quanto 
 necessario al gestore gli si può aggiungere questo valore per allocare uno
 stack di dimensione sufficiente.
 
 necessario al gestore gli si può aggiungere questo valore per allocare uno
 stack di dimensione sufficiente.
 

-Come accennato per poter essere usato lo stack per i segnali deve essere
+Come accennato, per poter essere usato, lo stack per i segnali deve essere

 indicato al sistema attraverso la funzione \funcd{sigaltstack}; il suo
 prototipo è:
 \begin{prototype}{signal.h}
 indicato al sistema attraverso la funzione \funcd{sigaltstack}; il suo
 prototipo è:
 \begin{prototype}{signal.h}


@@ -2146,7 +2139,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
 
 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. 
 
 In tal caso infatti si avrebbe un segnale di \const{SIGSEGV}, che potrebbe
 essere gestito soltanto avendo abilitato uno stack alternativo. 
 


@@ -2192,13 +2185,13 @@ due 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
-\index{salto~non-locale}; nel caso specifico essa è di tipo
+salvato il contesto dello stack per permettere il
+\index{salto~non-locale}salto non-locale; nel caso specifico essa è di tipo

 \type{sigjmp\_buf}, e non \type{jmp\_buf} come per le analoghe di
 sez.~\ref{sec:proc_longjmp} in quanto in questo caso viene salvata anche la
 maschera dei segnali.
 
 \type{sigjmp\_buf}, e non \type{jmp\_buf} come per le analoghe di
 sez.~\ref{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}
+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
 ripristinata in un successivo \func{siglongjmp}; quest'ultima funzione, a
 parte l'uso di \type{sigjmp\_buf} per \param{env}, è assolutamente identica a
 diverso da zero la maschera dei valori sarà salvata in \param{env} e
 ripristinata in un successivo \func{siglongjmp}; quest'ultima funzione, a
 parte l'uso di \type{sigjmp\_buf} per \param{env}, è assolutamente identica a


@@ -2220,11 +2213,11 @@ segnali classici:
 \item[I segnali non sono accumulati] 
   se più segnali vengono generati prima dell'esecuzione di un gestore
   questo sarà eseguito una sola volta, ed il processo non sarà in grado di
 \item[I segnali non sono accumulati] 
   se più segnali vengono generati prima dell'esecuzione di un gestore
   questo sarà eseguito una sola volta, ed il processo non sarà in grado di

-  accorgersi di quante volte l'evento che ha generato il segnale è accaduto.
+  accorgersi di quante volte l'evento che ha generato il segnale è accaduto;

 \item[I segnali non trasportano informazione]   
   i segnali classici non prevedono altra informazione sull'evento
   che li ha generati se non il fatto che sono stati emessi (tutta
 \item[I segnali non trasportano informazione]   
   i segnali classici non prevedono altra informazione sull'evento
   che li ha generati se non il fatto che sono stati emessi (tutta

-  l'informazione che il kernel associa ad un segnale è il suo numero).
+  l'informazione che il kernel associa ad un segnale è il suo numero);

 \item[I segnali non hanno un ordine di consegna] 
   l'ordine in cui diversi segnali vengono consegnati è casuale e non
   prevedibile. Non è possibile stabilire una priorità per cui la reazione a
 \item[I segnali non hanno un ordine di consegna] 
   l'ordine in cui diversi segnali vengono consegnati è casuale e non
   prevedibile. Non è possibile stabilire una priorità per cui la reazione a


@@ -2255,10 +2248,10 @@ Queste nuove funzionalit
 disponibile anche con i segnali ordinari) si applicano solo ai nuovi segnali
 real-time; questi ultimi sono accessibili in un range di valori specificati
 dalle due macro \const{SIGRTMIN} e \const{SIGRTMAX},\footnote{in Linux di
 disponibile anche con i segnali ordinari) si applicano solo ai nuovi segnali
 real-time; questi ultimi sono accessibili in un range di valori specificati
 dalle due macro \const{SIGRTMIN} e \const{SIGRTMAX},\footnote{in Linux di

-  solito il primo valore è 32, ed il secondo \code{\_NSIG-1}, che di norma è
-  63, per un totale di 32 segnali disponibili, contro gli almeno 8 richiesti
-  da POSIX.1b.} che specificano il numero minimo e massimo associato ad un
-segnale real-time.
+  solito (cioè sulla piattaforma i386) il primo valore è 33, ed il secondo
+  \code{\_NSIG-1}, che di norma è 64, per un totale di 32 segnali disponibili,
+  contro gli almeno 8 richiesti da POSIX.1b.} che specificano il numero minimo
+e massimo associato ad un segnale real-time.

 
 I segnali con un numero più basso hanno una priorità maggiore e vengono
 consegnati per primi, inoltre i segnali real-time non possono interrompere
 
 I segnali con un numero più basso hanno una priorità maggiore e vengono
 consegnati per primi, inoltre i segnali real-time non possono interrompere


@@ -2279,7 +2272,7 @@ gestori devono essere installati con \func{sigaction}, specificando per
 forma estesa \var{sa\_sigaction} (vedi sez.~\ref{sec:sig_sigaction}).  In
 questo modo tutti i segnali real-time possono restituire al gestore una serie
 di informazioni aggiuntive attraverso l'argomento \struct{siginfo\_t}, la cui
 forma estesa \var{sa\_sigaction} (vedi sez.~\ref{sec:sig_sigaction}).  In
 questo modo tutti i segnali real-time possono restituire al gestore una serie
 di informazioni aggiuntive attraverso l'argomento \struct{siginfo\_t}, la cui

-definizione abbiamo già visto in fig.~\ref{fig:sig_siginfo_t}, nella
+definizione è stata già vista in fig.~\ref{fig:sig_siginfo_t}, nella

 trattazione dei gestori in forma estesa.
 
 In particolare i campi utilizzati dai segnali real-time sono \var{si\_pid} e
 trattazione dei gestori in forma estesa.
 
 In particolare i campi utilizzati dai segnali real-time sono \var{si\_pid} e


@@ -2309,7 +2302,7 @@ alcune definizioni essa viene identificata anche come \code{union sigval}.
 \end{figure}
 
 A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
 \end{figure}
 
 A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad

-inviare segnali real-time, poichè non è in grado di fornire alcun valore
+inviare segnali real-time, poiché non è in grado di fornire alcun valore

 per \struct{sigval\_t}; per questo motivo lo standard ha previsto una nuova
 funzione, \funcd{sigqueue}, il cui prototipo è:
 \begin{prototype}{signal.h}
 per \struct{sigval\_t}; per questo motivo lo standard ha previsto una nuova
 funzione, \funcd{sigqueue}, il cui prototipo è:
 \begin{prototype}{signal.h}


@@ -2334,7 +2327,7 @@ funzione, \funcd{sigqueue}, il cui prototipo 
 
 Il comportamento della funzione è analogo a quello di \func{kill}, ed i
 privilegi occorrenti ad inviare il segnale ad un determinato processo sono gli
 
 Il comportamento della funzione è analogo a quello di \func{kill}, ed i
 privilegi occorrenti ad inviare il segnale ad un determinato processo sono gli

-stessi; un valore nullo di \func{signo} permette di verificare le condizioni
+stessi; un valore nullo di \param{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 è