2d9d439d17352a3f8653d108a449cefad06d8ac9
[gapil.git] / signal.tex
1 %% signal.tex
2 %%
3 %% Copyright (C) 2000-2007 Simone Piccardi.  Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
9 %% License".
10 %%
11
12 \chapter{I segnali}
13 \label{cha:signals}
14
15 I segnali sono il primo e più semplice meccanismo di comunicazione nei
16 confronti dei processi. Nella loro versione originale essi portano con sé
17 nessuna informazione che non sia il loro tipo; si tratta in sostanza di
18 un'interruzione software portata ad un processo.
19
20 In genere essi vengono usati dal kernel per riportare ai processi situazioni
21 eccezionali (come errori di accesso, eccezioni aritmetiche, ecc.) ma possono
22 anche essere usati come forma elementare di comunicazione fra processi (ad
23 esempio vengono usati per il controllo di sessione), per notificare eventi
24 (come la terminazione di un processo figlio), ecc.
25
26 In questo capitolo esamineremo i vari aspetti della gestione dei segnali,
27 partendo da una introduzione relativa ai concetti base con cui essi vengono
28 realizzati, per poi affrontarne la classificazione a secondo di uso e modalità
29 di generazione fino ad esaminare in dettaglio le funzioni e le metodologie di
30 gestione avanzate e le estensioni fatte all'interfaccia classica nelle nuovi
31 versioni dello standard POSIX.
32
33
34 \section{Introduzione}
35 \label{sec:sig_intro}
36
37 In questa sezione esamineremo i concetti generali relativi ai segnali, vedremo
38 le loro caratteristiche di base, introdurremo le nozioni di fondo relative
39 all'architettura del funzionamento dei segnali e alle modalità con cui il
40 sistema gestisce l'interazione fra di essi ed i processi.
41
42
43 \subsection{I concetti base}
44 \label{sec:sig_base}
45
46 Come il nome stesso indica i segnali sono usati per notificare ad un processo
47 l'occorrenza di un qualche evento. Gli eventi che possono generare un segnale
48 sono vari; un breve elenco di possibili cause per l'emissione di un segnale è
49 il seguente:
50
51 \begin{itemize*}
52 \item un errore del programma, come una divisione per zero o un tentativo di
53   accesso alla memoria fuori dai limiti validi;
54 \item la terminazione di un processo figlio;
55 \item la scadenza di un timer o di un allarme;
56 \item il tentativo di effettuare un'operazione di input/output che non può
57   essere eseguita;
58 \item una richiesta dell'utente di terminare o fermare il programma. In genere
59   si realizza attraverso un segnale mandato dalla shell in corrispondenza
60   della pressione di tasti del terminale come \code{C-c} o
61   \code{C-z};\footnote{indichiamo con \code{C-x} la pressione simultanea al
62     tasto \code{x} del tasto control (ctrl in molte tastiere).}
63 \item l'esecuzione di una \func{kill} o di una \func{raise} da parte del
64   processo stesso o di un altro (solo nel caso della \func{kill}).
65 \end{itemize*}
66
67 Ciascuno di questi eventi (compresi gli ultimi due che pure sono controllati
68 dall'utente o da un altro processo) comporta l'intervento diretto da parte del
69 kernel che causa la generazione di un particolare tipo di segnale.
70
71 Quando un processo riceve un segnale, invece del normale corso del programma,
72 viene eseguita una azione predefinita o una apposita funzione di gestione
73 (quello che da qui in avanti chiameremo il \textsl{gestore} del segnale,
74 dall'inglese \textit{signal handler}) che può essere stata specificata
75 dall'utente (nel qual caso si dice che si \textsl{intercetta} il segnale).
76
77
78 \subsection{Le \textsl{semantiche} del funzionamento dei segnali}
79 \label{sec:sig_semantics}
80
81 Negli anni il comportamento del sistema in risposta ai segnali è stato
82 modificato in vari modi nelle differenti implementazioni di Unix.  Si possono
83 individuare due tipologie fondamentali di comportamento dei segnali (dette
84 \textsl{semantiche}) che vengono chiamate rispettivamente \textsl{semantica
85   affidabile} (o \textit{reliable}) e \textsl{semantica inaffidabile} (o
86 \textit{unreliable}).
87
88 Nella \textsl{semantica inaffidabile} (quella implementata dalle prime
89 versioni di Unix) la funzione di gestione del segnale specificata dall'utente
90 non resta attiva una volta che è stata eseguita; è perciò compito dell'utente
91 stesso ripetere l'installazione all'interno del \textsl{gestore} del segnale,
92 in tutti quei casi in cui si vuole che esso resti attivo.
93
94 In questo caso è possibile una situazione in cui i segnali possono essere
95 perduti. Si consideri il segmento di codice riportato in
96 fig.~\ref{fig:sig_old_handler}, nel programma principale viene installato un
97 gestore (\texttt{\small 5}), ed in quest'ultimo la prima operazione
98 (\texttt{\small 11}) è quella di reinstallare se stesso. Se nell'esecuzione
99 del gestore un secondo segnale arriva prima che esso abbia potuto eseguire la
100 reinstallazione, verrà eseguito il comportamento predefinito assegnato al
101 segnale stesso, il che può comportare, a seconda dei casi, che il segnale
102 viene perso (se l'impostazione predefinita era quello di ignorarlo) o la
103 terminazione immediata del processo; in entrambi i casi l'azione prevista non
104 verrà eseguita.
105
106 \begin{figure}[!htb]
107   \footnotesize \centering
108   \begin{minipage}[c]{15cm}
109     \includecodesample{listati/unreliable_sig.c}
110   \end{minipage} 
111   \normalsize 
112   \caption{Esempio di codice di un gestore di segnale per la semantica
113     inaffidabile.} 
114   \label{fig:sig_old_handler}
115 \end{figure}
116
117 Questa è la ragione per cui l'implementazione dei segnali secondo questa
118 semantica viene chiamata \textsl{inaffidabile}; infatti la ricezione del
119 segnale e la reinstallazione del suo gestore non sono operazioni atomiche, e
120 sono sempre possibili delle \itindex{race~condition} \textit{race condition}
121 (sull'argomento vedi quanto detto in sez.~\ref{sec:proc_multi_prog}).
122
123 Un altro problema è che in questa semantica non esiste un modo per bloccare i
124 segnali quando non si vuole che arrivino; i processi possono ignorare il
125 segnale, ma non è possibile istruire il sistema a non fare nulla in occasione
126 di un segnale, pur mantenendo memoria del fatto che è avvenuto.
127
128 Nella semantica \textsl{affidabile} (quella utilizzata da Linux e da ogni Unix
129 moderno) il gestore una volta installato resta attivo e non si hanno tutti i
130 problemi precedenti. In questa semantica i segnali vengono \textsl{generati}
131 dal kernel per un processo all'occorrenza dell'evento che causa il segnale. In
132 genere questo viene fatto dal kernel impostando l'apposito campo della
133 \struct{task\_struct} del processo nella \itindex{process~table}
134 \textit{process table} (si veda fig.~\ref{fig:proc_task_struct}).
135
136 Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
137 \textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
138 per tutto il tempo che passa fra la generazione del segnale e la sua consegna
139 esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
140 procedura viene effettuata dallo \itindex{scheduler} scheduler quando,
141 riprendendo l'esecuzione del processo in questione, verifica la presenza del
142 segnale nella \struct{task\_struct} e mette in esecuzione il gestore.
143
144 In questa semantica un processo ha la possibilità di bloccare la consegna dei
145 segnali, in questo caso, se l'azione per il suddetto segnale non è quella di
146 ignorarlo, il segnale resta \textsl{pendente} fintanto che il processo non lo
147 sblocca (nel qual caso viene consegnato) o imposta l'azione corrispondente per
148 ignorarlo.
149
150 Si tenga presente che il kernel stabilisce cosa fare con un segnale che è
151 stato bloccato al momento della consegna, non quando viene generato; questo
152 consente di cambiare l'azione per il segnale prima che esso venga consegnato,
153 e si può usare la funzione \func{sigpending} (vedi sez.~\ref{sec:sig_sigmask})
154 per determinare quali segnali sono bloccati e quali sono pendenti.
155
156
157 \subsection{Tipi di segnali}
158 \label{sec:sig_types}
159
160 In generale gli eventi che generano segnali si possono dividere in tre
161 categorie principali: errori, eventi esterni e richieste esplicite.
162
163 Un errore significa che un programma ha fatto qualcosa di sbagliato e non può
164 continuare ad essere eseguito. Non tutti gli errori causano dei segnali, in
165 genere le condizioni di errore più comuni comportano la restituzione di un
166 codice di errore da parte di una funzione di libreria; sono gli errori che
167 possono avvenire nella esecuzione delle istruzioni di un programma che causano
168 l'emissione di un segnale, come le divisioni per zero o l'uso di indirizzi di
169 memoria non validi.
170
171 Un evento esterno ha in genere a che fare con l'I/O o con altri processi;
172 esempi di segnali di questo tipo sono quelli legati all'arrivo di dati di
173 input, scadenze di un timer, terminazione di processi figli.
174
175 Una richiesta esplicita significa l'uso di una chiamata di sistema (come
176 \func{kill} o \func{raise}) per la generazione di un segnale, cosa che
177 viene fatta usualmente dalla shell quando l'utente invoca la sequenza di tasti
178 di stop o di suspend, ma può essere pure inserita all'interno di un programma.
179
180 Si dice poi che i segnali possono essere \textsl{asincroni} o
181 \textsl{sincroni}. Un segnale \textsl{sincrono} è legato ad una azione
182 specifica di un programma ed è inviato (a meno che non sia bloccato) durante
183 tale azione; molti errori generano segnali \textsl{sincroni}, così come la
184 richiesta esplicita da parte del processo tramite le chiamate al sistema.
185 Alcuni errori come la divisione per zero non sono completamente sincroni e
186 possono arrivare dopo qualche istruzione.
187
188 I segnali \textsl{asincroni} sono generati da eventi fuori dal controllo del
189 processo che li riceve, e arrivano in tempi impredicibili nel corso
190 dell'esecuzione del programma. Eventi esterni come la terminazione di un
191 processo figlio generano segnali \textsl{asincroni}, così come le richieste di
192 generazione di un segnale effettuate da altri processi.
193
194 In generale un tipo di segnale o è sincrono o è asincrono, salvo il caso in
195 cui esso sia generato attraverso una richiesta esplicita tramite chiamata al
196 sistema, nel qual caso qualunque tipo di segnale (quello scelto nella
197 chiamata) può diventare sincrono o asincrono a seconda che sia generato
198 internamente o esternamente al processo.
199
200
201 \subsection{La notifica dei segnali}
202 \label{sec:sig_notification}
203
204 Come accennato quando un segnale viene generato, se la sua azione predefinita
205 non è quella di essere ignorato, il kernel prende nota del fatto nella
206 \struct{task\_struct} del processo; si dice così che il segnale diventa
207 \textsl{pendente} (o \textit{pending}), e rimane tale fino al momento in cui
208 verrà notificato al processo (o verrà specificata come azione quella di
209 ignorarlo).
210
211 Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
212 avviene non appena questo viene rimesso in esecuzione dallo
213 \itindex{scheduler} scheduler che esegue l'azione specificata. Questo a meno
214 che il segnale in questione non sia stato bloccato prima della notifica, nel
215 qual caso l'invio non avviene ed il segnale resta \textsl{pendente}
216 indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
217 notificato. Si tenga presente però che i segnali \textsl{pendenti} non si
218 accodano, alla generazione infatti il kernel marca un flag nella
219 \struct{task\_struct} del processo, per cui se prima della notifica ne vengono
220 generati altri il flag è comunque marcato, ed il gestore viene eseguito sempre
221 una sola volta.
222
223 Si ricordi però che se l'azione specificata per un segnale è quella di essere
224 ignorato questo sarà scartato immediatamente al momento della sua generazione,
225 e questo anche se in quel momento il segnale è bloccato (perché bloccare su un
226 segnale significa bloccarne la notifica). Per questo motivo un segnale,
227 fintanto che viene ignorato, non sarà mai notificato, anche se prima è stato
228 bloccato ed in seguito si è specificata una azione diversa (nel qual caso solo
229 i segnali successivi alla nuova specificazione saranno notificati).
230
231 Una volta che un segnale viene notificato (che questo avvenga subito o dopo
232 una attesa più o meno lunga) viene eseguita l'azione specificata per il
233 segnale. Per alcuni segnali (\const{SIGKILL} e \const{SIGSTOP}) questa azione
234 è fissa e non può essere cambiata, ma per tutti gli altri si può selezionare
235 una  delle tre possibilità seguenti:
236
237 \begin{itemize*}
238 \item ignorare il segnale;
239 \item catturare il segnale, ed utilizzare il gestore specificato;
240 \item accettare l'azione predefinita per quel segnale.
241 \end{itemize*}
242
243 Un programma può specificare queste scelte usando le due funzioni
244 \func{signal} e \func{sigaction} (vedi sez.~\ref{sec:sig_signal} e
245 sez.~\ref{sec:sig_sigaction}). Se si è installato un gestore sarà quest'ultimo
246 ad essere eseguito alla notifica del segnale.  Inoltre il sistema farà si che
247 mentre viene eseguito il gestore di un segnale, quest'ultimo venga
248 automaticamente bloccato (così si possono evitare \itindex{race~condition}
249 \textit{race condition}).
250
251 Nel caso non sia stata specificata un'azione, viene utilizzata l'azione
252 standard che (come vedremo in sez.~\ref{sec:sig_standard}) è propria di ciascun
253 segnale; nella maggior parte dei casi essa porta alla terminazione del
254 processo, ma alcuni segnali che rappresentano eventi innocui vengono ignorati.
255
256 Quando un segnale termina un processo, il padre può determinare la causa della
257 terminazione esaminando il codice di stato riportato dalle funzioni
258 \func{wait} e \func{waitpid} (vedi sez.~\ref{sec:proc_wait}); questo è il modo
259 in cui la shell determina i motivi della terminazione di un programma e scrive
260 un eventuale messaggio di errore.
261
262 I segnali che rappresentano errori del programma (divisione per zero o
263 violazioni di accesso) hanno anche la caratteristica di scrivere un file di
264 \itindex{core~dump} \textit{core dump} che registra lo stato del processo (ed
265 in particolare della memoria e dello \itindex{stack} stack) prima della
266 terminazione.  Questo può essere esaminato in seguito con un debugger per
267 investigare sulla causa dell'errore.  Lo stesso avviene se i suddetti segnali
268 vengono generati con una \func{kill}.
269
270
271 \section{La classificazione dei segnali}
272 \label{sec:sig_classification}
273
274 Esamineremo in questa sezione quali sono i vari segnali definiti nel sistema,
275 le loro caratteristiche e tipologia, le varie macro e costanti che permettono
276 di identificarli, e le funzioni che ne stampano la descrizione.
277
278
279 \subsection{I segnali standard}
280 \label{sec:sig_standard}
281
282 Ciascun segnale è identificato rispetto al sistema da un numero, ma l'uso
283 diretto di questo numero da parte dei programmi è da evitare, in quanto esso
284 può variare a seconda dell'implementazione del sistema, e nel caso di Linux,
285 anche a seconda dell'architettura hardware. 
286 Per questo motivo ad ogni segnale viene associato un nome, definendo con una
287 macro di preprocessore una costante uguale al suddetto numero. Sono questi
288 nomi, che sono standardizzati e sostanzialmente uniformi rispetto alle varie
289 implementazioni, che si devono usare nei programmi. Tutti i nomi e le funzioni
290 che concernono i segnali sono definiti nell'header di sistema \file{signal.h}.
291
292 Il numero totale di segnali presenti è dato dalla macro \const{NSIG}, e dato
293 che i numeri dei segnali sono allocati progressivamente, essa corrisponde
294 anche al successivo del valore numerico assegnato all'ultimo segnale definito.
295 In tab.~\ref{tab:sig_signal_list} si è riportato l'elenco completo dei segnali
296 definiti in Linux (estratto dalle pagine di manuale), comparati con quelli
297 definiti in vari standard.
298
299 \begin{table}[htb]
300   \footnotesize
301   \centering
302   \begin{tabular}[c]{|c|p{8cm}|}
303     \hline
304     \textbf{Sigla} & \textbf{Significato} \\
305     \hline
306     \hline
307     A & L'azione predefinita è terminare il processo. \\
308     B & L'azione predefinita è ignorare il segnale. \\
309     C & L'azione predefinita è terminare il processo e scrivere un 
310         \itindex{core~dump} \textit{core dump}. \\
311     D & L'azione predefinita è fermare il processo. \\
312     E & Il segnale non può essere intercettato. \\
313     F & Il segnale non può essere ignorato.\\
314     \hline
315   \end{tabular}
316   \caption{Legenda delle azioni predefinite dei segnali riportate in 
317     tab.~\ref{tab:sig_signal_list}.}
318   \label{tab:sig_action_leg}
319 \end{table}
320
321 In tab.~\ref{tab:sig_signal_list} si sono anche riportate le azioni predefinite
322 di ciascun segnale (riassunte con delle lettere, la cui legenda completa è in
323 tab.~\ref{tab:sig_action_leg}), quando nessun gestore è installato un
324 segnale può essere ignorato o causare la terminazione del processo. Nella
325 colonna standard sono stati indicati anche gli standard in cui ciascun segnale
326 è definito, secondo lo schema di tab.~\ref{tab:sig_standard_leg}.
327
328
329 \begin{table}[htb]
330   \footnotesize
331   \centering
332   \begin{tabular}[c]{|c|l|}
333     \hline
334     \textbf{Sigla} & \textbf{Standard} \\
335     \hline
336     \hline
337     P & POSIX. \\
338     B & BSD. \\
339     L & Linux.\\
340     S & SUSv2.\\
341     \hline
342   \end{tabular}
343   \caption{Legenda dei valori della colonna \textbf{Standard} di 
344     tab.~\ref{tab:sig_signal_list}.}
345   \label{tab:sig_standard_leg}
346 \end{table}
347
348 In alcuni casi alla terminazione del processo è associata la creazione di un
349 file (posto nella directory corrente del processo e chiamato \file{core}) su
350 cui viene salvata un'immagine della memoria del processo (il cosiddetto
351 \itindex{core~dump} \textit{core dump}), che può essere usata da un debugger
352 per esaminare lo stato dello \itindex{stack} stack e delle variabili al
353 momento della ricezione del segnale.
354
355 \begin{table}[htb]
356   \footnotesize
357   \centering
358   \begin{tabular}[c]{|l|c|c|p{8cm}|}
359     \hline
360     \textbf{Segnale} &\textbf{Standard}&\textbf{Azione}&\textbf{Descrizione} \\
361     \hline
362     \hline
363     \const{SIGHUP}   &PL & A & Hangup o terminazione del processo di 
364                                controllo.                                    \\
365     \const{SIGINT}   &PL & A & Interrupt da tastiera (\cmd{C-c}).            \\
366     \const{SIGQUIT}  &PL & C & Quit da tastiera (\cmd{C-y}).                 \\
367     \const{SIGILL}   &PL & C & Istruzione illecita.                          \\
368     \const{SIGABRT}  &PL & C & Segnale di abort da \func{abort}.             \\
369     \const{SIGFPE}   &PL & C & Errore aritmetico.                            \\
370     \const{SIGKILL}  &PL &AEF& Segnale di terminazione forzata.              \\
371     \const{SIGSEGV}  &PL & C & Errore di accesso in memoria.                 \\
372     \const{SIGPIPE}  &PL & A & Pipe spezzata.                                \\
373     \const{SIGALRM}  &PL & A & Segnale del timer da \func{alarm}.            \\
374     \const{SIGTERM}  &PL & A & Segnale di terminazione \texttt{C-\bslash}.   \\
375     \const{SIGUSR1}  &PL & A & Segnale utente numero 1.                      \\
376     \const{SIGUSR2}  &PL & A & Segnale utente numero 2.                      \\
377     \const{SIGCHLD}  &PL & B & Figlio terminato o fermato.                   \\
378     \const{SIGCONT}  &PL &   & Continua se fermato.                          \\
379     \const{SIGSTOP}  &PL &DEF& Ferma il processo.                            \\
380     \const{SIGTSTP}  &PL & D & Pressione del tasto di stop sul terminale.    \\
381     \const{SIGTTIN}  &PL & D & Input sul terminale per un processo 
382                                in background.                                \\
383     \const{SIGTTOU}  &PL & D & Output sul terminale per un processo          
384                                in background.                                \\
385     \const{SIGBUS}   &SL & C & Errore sul bus (bad memory access).           \\
386     \const{SIGPOLL}  &SL & A & \textit{Pollable event} (Sys V);  
387                                Sinonimo di \const{SIGIO}.                    \\
388     \const{SIGPROF}  &SL & A & Timer del profiling scaduto.                  \\
389     \const{SIGSYS}   &SL & C & Argomento sbagliato per una subroutine (SVID).\\
390     \const{SIGTRAP}  &SL & C & Trappole per un Trace/breakpoint.             \\
391     \const{SIGURG}   &SLB& B & Ricezione di una \textit{urgent condition} su 
392                                un socket. \\
393     \const{SIGVTALRM}&SLB& A & Virtual alarm clock.                          \\
394     \const{SIGXCPU}  &SLB& C & Ecceduto il limite sul tempo di CPU.          \\
395     \const{SIGXFSZ}  &SLB& C & Ecceduto il limite sulla dimensione dei file. \\
396     \const{SIGIOT}   &L  & C & IOT trap. Sinonimo di \const{SIGABRT}.        \\
397     \const{SIGEMT}   &L  &   &                                               \\
398 % TODO che roba e` SIGEMT
399     \const{SIGSTKFLT}&L  & A & Errore sullo stack del coprocessore.          \\
400     \const{SIGIO}    &LB & A & L'I/O è possibile (4.2 BSD).                  \\
401     \const{SIGCLD}   &L  &   & Sinonimo di \const{SIGCHLD}.                  \\
402     \const{SIGPWR}   &L  & A & Fallimento dell'alimentazione.                \\
403     \const{SIGINFO}  &L  &   & Sinonimo di \const{SIGPWR}.                   \\
404     \const{SIGLOST}  &L  & A & Perso un lock sul file (per NFS).             \\
405     \const{SIGWINCH} &LB & B & Finestra ridimensionata (4.3 BSD, Sun).       \\
406     \const{SIGUNUSED}&L  & A & Segnale inutilizzato (diventerà 
407                                \const{SIGSYS}).                              \\
408     \hline
409   \end{tabular}
410   \caption{Lista dei segnali in Linux.}
411   \label{tab:sig_signal_list}
412 \end{table}
413
414 La descrizione dettagliata del significato dei vari segnali, raggruppati per
415 tipologia, verrà affrontata nei paragrafi successivi.
416
417
418 \subsection{Segnali di errore di programma}
419 \label{sec:sig_prog_error}
420
421 Questi segnali sono generati quando il sistema, o in certi casi direttamente
422 l'hardware (come per i \itindex{page~fault} \textit{page fault} non validi)
423 rileva un qualche errore insanabile nel programma in esecuzione. In generale
424 la generazione di questi segnali significa che il programma ha dei gravi
425 problemi (ad esempio ha dereferenziato un puntatore non valido o ha eseguito
426 una operazione aritmetica proibita) e l'esecuzione non può essere proseguita.
427
428 In genere si intercettano questi segnali per permettere al programma di
429 terminare in maniera pulita, ad esempio per ripristinare le impostazioni della
430 console o eliminare i \index{file!di lock} file di lock prima dell'uscita.  In
431 questo caso il gestore deve concludersi ripristinando l'azione predefinita e
432 rialzando il segnale, in questo modo il programma si concluderà senza effetti
433 spiacevoli, ma riportando lo stesso stato di uscita che avrebbe avuto se il
434 gestore non ci fosse stato.
435
436 L'azione predefinita per tutti questi segnali è causare la terminazione del
437 processo che li ha causati. In genere oltre a questo il segnale provoca pure
438 la registrazione su disco di un file di \itindex{core~dump} \textit{core dump}
439 che viene scritto in un file \file{core} nella directory corrente del processo
440 al momento dell'errore, che il debugger può usare per ricostruire lo stato del
441 programma al momento della terminazione.  Questi segnali sono:
442 \begin{basedescript}{\desclabelwidth{2.0cm}}
443 \item[\const{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome
444   derivi da \textit{floating point exception} si applica a tutti gli errori
445   aritmetici compresa la divisione per zero e l'overflow.  Se il gestore
446   ritorna il comportamento del processo è indefinito, ed ignorare questo
447   segnale può condurre ad un ciclo infinito.
448
449 %   Per questo segnale le cose sono complicate dal fatto che possono esserci
450 %   molte diverse eccezioni che \texttt{SIGFPE} non distingue, mentre lo
451 %   standard IEEE per le operazioni in virgola mobile definisce varie eccezioni
452 %   aritmetiche e richiede che esse siano notificate.  
453 % TODO trovare altre info su SIGFPE e trattare la notifica delle eccezioni 
454   
455 \item[\const{SIGILL}] Il nome deriva da \textit{illegal instruction},
456   significa che il programma sta cercando di eseguire una istruzione
457   privilegiata o inesistente, in generale del codice illecito. Poiché il
458   compilatore del C genera del codice valido si ottiene questo segnale se il
459   file eseguibile è corrotto o si stanno cercando di eseguire dei dati.
460   Quest'ultimo caso può accadere quando si passa un puntatore sbagliato al
461   posto di un puntatore a funzione, o si eccede la scrittura di un vettore di
462   una variabile locale, andando a corrompere lo \itindex{stack} stack. Lo
463   stesso segnale viene generato in caso di overflow dello \itindex{stack}
464   stack o di problemi nell'esecuzione di un gestore. Se il gestore ritorna il
465   comportamento del processo è indefinito.
466 \item[\const{SIGSEGV}] Il nome deriva da \textit{segment violation}, e
467   significa che il programma sta cercando di leggere o scrivere in una zona di
468   memoria protetta al di fuori di quella che gli è stata riservata dal
469   sistema. In genere è il meccanismo della protezione della memoria che si
470   accorge dell'errore ed il kernel genera il segnale.  Se il gestore
471   ritorna il comportamento del processo è indefinito.
472
473   È tipico ottenere questo segnale dereferenziando un puntatore nullo o non
474   inizializzato leggendo al di là della fine di un vettore. 
475 \item[\const{SIGBUS}] Il nome deriva da \textit{bus error}. Come
476   \const{SIGSEGV} questo è un segnale che viene generato di solito quando si
477   dereferenzia un puntatore non inizializzato, la differenza è che
478   \const{SIGSEGV} indica un accesso non permesso su un indirizzo esistente
479   (tipo fuori dallo heap o dallo \itindex{stack} stack), mentre \const{SIGBUS}
480   indica l'accesso ad un indirizzo non valido, come nel caso di un puntatore
481   non allineato.
482 \item[\const{SIGABRT}] Il nome deriva da \textit{abort}. Il segnale indica che
483   il programma stesso ha rilevato un errore che viene riportato chiamando la
484   funzione \func{abort} che genera questo segnale.
485 \item[\const{SIGTRAP}] È il segnale generato da un'istruzione di breakpoint o
486   dall'attivazione del tracciamento per il processo. È usato dai programmi per
487   il debugging e un programma normale non dovrebbe ricevere questo segnale.
488 \item[\const{SIGSYS}] Sta ad indicare che si è eseguita una istruzione che
489   richiede l'esecuzione di una system call, ma si è fornito un codice
490   sbagliato per quest'ultima.
491 \end{basedescript}
492
493
494 \subsection{I segnali di terminazione}
495 \label{sec:sig_termination}
496
497 Questo tipo di segnali sono usati per terminare un processo; hanno vari nomi a
498 causa del differente uso che se ne può fare, ed i programmi possono
499 trattarli in maniera differente. 
500
501 La ragione per cui può essere necessario trattare questi segnali è che il
502 programma può dover eseguire una serie di azioni di pulizia prima di
503 terminare, come salvare informazioni sullo stato in cui si trova, cancellare
504 file temporanei, o ripristinare delle condizioni alterate durante il
505 funzionamento (come il modo del terminale o le impostazioni di una qualche
506 periferica).
507
508 L'azione predefinita di questi segnali è di terminare il processo, questi
509 segnali sono:
510 \begin{basedescript}{\desclabelwidth{2.0cm}}
511 \item[\const{SIGTERM}] Il nome sta per \textit{terminate}. È un segnale
512   generico usato per causare la conclusione di un programma. Al contrario di
513   \const{SIGKILL} può essere intercettato, ignorato, bloccato. In genere lo si
514   usa per chiedere in maniera ``\textsl{educata}'' ad un processo di
515   concludersi.
516
517 \item[\const{SIGINT}] Il nome sta per \textit{interrupt}. È il segnale di
518   interruzione per il programma. È quello che viene generato di default dal
519   comando \cmd{kill} o dall'invio sul terminale del carattere di controllo
520   INTR (interrupt, generato dalla sequenza \cmd{C-c}).
521
522 \item[\const{SIGQUIT}] È analogo a \const{SIGINT} con la differenza che è
523   controllato da un altro carattere di controllo, QUIT, corrispondente alla
524   sequenza \texttt{C-\bslash}. A differenza del precedente l'azione
525   predefinita, oltre alla terminazione del processo, comporta anche la
526   creazione di un \itindex{core~dump} \textit{core dump}.
527
528   In genere lo si può pensare come corrispondente ad una condizione di errore
529   del programma rilevata dall'utente. Per questo motivo non è opportuno fare
530   eseguire al gestore di questo segnale le operazioni di pulizia normalmente
531   previste (tipo la cancellazione di file temporanei), dato che in certi casi
532   esse possono eliminare informazioni utili nell'esame dei \itindex{core~dump}
533   \textit{core dump}.
534   
535
536 \item[\const{SIGKILL}] Il nome è utilizzato per terminare in maniera immediata
537   qualunque programma. Questo segnale non può essere né intercettato, né
538   ignorato, né bloccato, per cui causa comunque la terminazione del processo.
539   In genere esso viene generato solo per richiesta esplicita dell'utente dal
540   comando (o tramite la funzione) \cmd{kill}. Dato che non lo si può
541   intercettare è sempre meglio usarlo come ultima risorsa quando metodi meno
542   brutali, come \const{SIGTERM} o \cmd{C-c} non funzionano. 
543
544   Se un processo non risponde a nessun altro segnale \const{SIGKILL} ne causa
545   sempre la terminazione (in effetti il fallimento della terminazione di un
546   processo da parte di \const{SIGKILL} costituirebbe un malfunzionamento del
547   kernel). Talvolta è il sistema stesso che può generare questo segnale quando
548   per condizioni particolari il processo non può più essere eseguito neanche
549   per eseguire un gestore.
550
551 \item[\const{SIGHUP}] Il nome sta per \textit{hang-up}. Segnala che il
552   terminale dell'utente si è disconnesso (ad esempio perché si è interrotta la
553   rete). Viene usato anche per riportare la terminazione del processo di
554   controllo di un terminale a tutti i processi della sessione, in modo che
555   essi possano disconnettersi dal relativo terminale. 
556   
557   Viene inoltre usato in genere per segnalare ai demoni (che non hanno un
558   terminale di controllo) la necessità di reinizializzarsi e rileggere il/i
559   file di configurazione.
560 \end{basedescript}
561
562
563 \subsection{I segnali di allarme}
564 \label{sec:sig_alarm}
565
566 Questi segnali sono generati dalla scadenza di un timer. Il loro comportamento
567 predefinito è quello di causare la terminazione del programma, ma con questi
568 segnali la scelta predefinita è irrilevante, in quanto il loro uso presuppone
569 sempre la necessità di un gestore.  Questi segnali sono:
570 \begin{basedescript}{\desclabelwidth{2.0cm}}
571 \item[\const{SIGALRM}] Il nome sta per \textit{alarm}. Segnale la scadenza di
572   un timer misurato sul tempo reale o sull'orologio di sistema. È normalmente
573   usato dalla funzione \func{alarm}.
574
575 \item[\const{SIGVTALRM}] Il nome sta per \textit{virtual alarm}. È analogo al
576   precedente ma segnala la scadenza di un timer sul tempo di CPU usato dal
577   processo. 
578
579 \item[\const{SIGPROF}] Il nome sta per \textit{profiling}. Indica la scadenza
580   di un timer che misura sia il tempo di CPU speso direttamente dal processo
581   che quello che il sistema ha speso per conto di quest'ultimo. In genere
582   viene usato dagli strumenti che servono a fare la profilazione dell'utilizzo
583   del tempo di CPU da parte del processo.
584 \end{basedescript}
585
586
587 \subsection{I segnali di I/O asincrono}
588 \label{sec:sig_asyncio}
589
590 Questi segnali operano in congiunzione con le funzioni di I/O asincrono. Per
591 questo occorre comunque usare \func{fcntl} per abilitare un file descriptor a
592 generare questi segnali.  L'azione predefinita è di essere ignorati. Questi
593 segnali sono:
594 \begin{basedescript}{\desclabelwidth{2.0cm}}
595 \item[\const{SIGIO}] Questo segnale viene inviato quando un file descriptor è
596   pronto per eseguire dell'input/output. In molti sistemi solo i
597   socket e i terminali possono generare questo segnale, in Linux
598   questo può essere usato anche per i file, posto che la \func{fcntl} abbia
599   avuto successo.
600
601 \item[\const{SIGURG}] Questo segnale è inviato quando arrivano dei dati
602   urgenti o \itindex{out-of-band} \textit{out-of-band} su di un
603   socket; per maggiori dettagli al proposito si veda
604   sez.~\ref{sec:TCP_urgent_data}.
605
606 \item[\const{SIGPOLL}] Questo segnale è equivalente a \const{SIGIO}, è
607   definito solo per compatibilità con i sistemi System V.
608 \end{basedescript}
609
610
611 \subsection{I segnali per il controllo di sessione}
612 \label{sec:sig_job_control}
613
614 Questi sono i segnali usati dal controllo delle sessioni e dei processi, il
615 loro uso è specializzato e viene trattato in maniera specifica nelle sezioni
616 in cui si trattano gli argomenti relativi.  Questi segnali sono:
617 \begin{basedescript}{\desclabelwidth{2.0cm}}
618 \item[\const{SIGCHLD}] Questo è il segnale mandato al processo padre quando un
619   figlio termina o viene fermato. L'azione predefinita è di ignorare il
620   segnale, la sua gestione è trattata in sez.~\ref{sec:proc_wait}.
621
622 \item[\const{SIGCLD}] Per Linux questo è solo un segnale identico al
623   precedente, il nome è obsoleto e andrebbe evitato. 
624
625 \item[\const{SIGCONT}] Il nome sta per \textit{continue}. Il segnale viene
626   usato per fare ripartire un programma precedentemente fermato da
627   \const{SIGSTOP}. Questo segnale ha un comportamento speciale, e fa sempre
628   ripartire il processo prima della sua consegna. Il comportamento predefinito
629   è di fare solo questo; il segnale non può essere bloccato. Si può anche
630   installare un gestore, ma il segnale provoca comunque il riavvio del
631   processo.
632   
633   La maggior pare dei programmi non hanno necessità di intercettare il
634   segnale, in quanto esso è completamente trasparente rispetto all'esecuzione
635   che riparte senza che il programma noti niente. Si possono installare dei
636   gestori per far si che un programma produca una qualche azione speciale
637   se viene fermato e riavviato, come per esempio riscrivere un prompt, o
638   inviare un avviso. 
639 \item[\const{SIGSTOP}] Il segnale ferma un processo (lo porta cioè in uno
640   stato di sleep, vedi sez.~\ref{sec:proc_sched}); il segnale non può essere né
641   intercettato, né ignorato, né bloccato.
642
643 \item[\const{SIGTSTP}] Il nome sta per \textit{interactive stop}. Il segnale
644   ferma il processo interattivamente, ed è generato dal carattere SUSP
645   (prodotto dalla combinazione \cmd{C-z}), ed al contrario di
646   \const{SIGSTOP} può essere intercettato e ignorato. In genere un programma
647   installa un gestore per questo segnale quando vuole lasciare il sistema
648   o il terminale in uno stato definito prima di fermarsi; se per esempio un
649   programma ha disabilitato l'eco sul terminale può installare un gestore
650   per riabilitarlo prima di fermarsi.
651
652 \item[\const{SIGTTIN}] Un processo non può leggere dal terminale se esegue una
653   sessione di lavoro in \textit{background}. Quando un processo in background
654   tenta di leggere da un terminale viene inviato questo segnale a tutti i
655   processi della sessione di lavoro. L'azione predefinita è di fermare il
656   processo.  L'argomento è trattato in
657   sez.~\ref{sec:sess_job_control_overview}.
658
659 \item[\const{SIGTTOU}] Segnale analogo al precedente \const{SIGTTIN}, ma
660   generato quando si tenta di scrivere o modificare uno dei modi del
661   terminale. L'azione predefinita è di fermare il processo, l'argomento è
662   trattato in sez.~\ref{sec:sess_job_control_overview}.
663 \end{basedescript}
664
665
666 \subsection{I segnali di operazioni errate}
667 \label{sec:sig_oper_error}
668
669 Questi segnali sono usati per riportare al programma errori generati da
670 operazioni da lui eseguite; non indicano errori del programma quanto errori
671 che impediscono il completamento dell'esecuzione dovute all'interazione con il
672 resto del sistema.  L'azione predefinita di questi segnali è di terminare il
673 processo, questi segnali sono:
674 \begin{basedescript}{\desclabelwidth{2.0cm}}
675 \item[\const{SIGPIPE}] Sta per \textit{Broken pipe}. Se si usano delle pipe,
676   (o delle FIFO o dei socket) è necessario, prima che un processo inizi a
677   scrivere su una di esse, che un altro l'abbia aperta in lettura (si veda
678   sez.~\ref{sec:ipc_pipes}). Se il processo in lettura non è partito o è
679   terminato inavvertitamente alla scrittura sulla pipe il kernel genera questo
680   segnale. Se il segnale è bloccato, intercettato o ignorato la chiamata che
681   lo ha causato fallisce, restituendo l'errore \errcode{EPIPE}.
682 \item[\const{SIGLOST}] Sta per \textit{Resource lost}. Tradizionalmente è il
683   segnale che viene generato quando si perde un advisory lock su un file su
684   NFS perché il server NFS è stato riavviato. Il progetto GNU lo utilizza per
685   indicare ad un client il crollo inaspettato di un server. In Linux è
686   definito come sinonimo di \const{SIGIO}.\footnote{ed è segnalato come BUG
687     nella pagina di manuale.}
688 \item[\const{SIGXCPU}] Sta per \textit{CPU time limit exceeded}. Questo
689   segnale è generato quando un processo eccede il limite impostato per il
690   tempo di CPU disponibile, vedi sez.~\ref{sec:sys_resource_limit}. 
691 \item[\const{SIGXFSZ}] Sta per \textit{File size limit exceeded}. Questo
692   segnale è generato quando un processo tenta di estendere un file oltre le
693   dimensioni specificate dal limite impostato per le dimensioni massime di un
694   file, vedi sez.~\ref{sec:sys_resource_limit}. 
695 \end{basedescript}
696
697
698 \subsection{Ulteriori segnali}
699 \label{sec:sig_misc_sig}
700
701 Raccogliamo qui infine una serie di segnali che hanno scopi differenti non
702 classificabili in maniera omogenea. Questi segnali sono:
703 \begin{basedescript}{\desclabelwidth{2.0cm}}
704 \item[\const{SIGUSR1}] Insieme a \const{SIGUSR2} è un segnale a disposizione
705   dell'utente che lo può usare per quello che vuole. Viene generato solo
706   attraverso l'invocazione della funzione \func{kill}. Entrambi i segnali
707   possono essere utili per implementare una comunicazione elementare fra
708   processi diversi, o per eseguire a richiesta una operazione utilizzando un
709   gestore. L'azione predefinita è di terminare il processo.
710 \item[\const{SIGUSR2}] È il secondo segnale a disposizione degli utenti. Vedi
711   quanto appena detto per \const{SIGUSR1}.
712 \item[\const{SIGWINCH}] Il nome sta per \textit{window (size) change} e viene
713   generato in molti sistemi (GNU/Linux compreso) quando le dimensioni (in
714   righe e colonne) di un terminale vengono cambiate. Viene usato da alcuni
715   programmi testuali per riformattare l'uscita su schermo quando si cambia
716   dimensione a quest'ultimo. L'azione predefinita è di essere ignorato.
717 \item[\const{SIGINFO}] Il segnale indica una richiesta di informazioni. È
718   usato con il controllo di sessione, causa la stampa di informazioni da parte
719   del processo leader del gruppo associato al terminale di controllo, gli
720   altri processi lo ignorano.
721 \end{basedescript}
722
723
724 \subsection{Le funzioni \func{strsignal} e \func{psignal}}
725 \label{sec:sig_strsignal}
726
727 Per la descrizione dei segnali il sistema mette a disposizione due funzioni
728 che stampano un messaggio di descrizione dato il numero. In genere si usano
729 quando si vuole notificare all'utente il segnale ricevuto (nel caso di
730 terminazione di un processo figlio o di un gestore che gestisce più segnali);
731 la prima funzione, \funcd{strsignal}, è una estensione GNU, accessibile avendo
732 definito \macro{\_GNU\_SOURCE}, ed è analoga alla funzione \func{strerror} (si
733 veda sez.~\ref{sec:sys_strerror}) per gli errori:
734 \begin{prototype}{string.h}{char *strsignal(int signum)} 
735   Ritorna il puntatore ad una stringa che contiene la descrizione del segnale
736   \param{signum}.
737 \end{prototype}
738 \noindent dato che la stringa è allocata staticamente non se ne deve
739 modificare il contenuto, che resta valido solo fino alla successiva chiamata
740 di \func{strsignal}. Nel caso si debba mantenere traccia del messaggio sarà
741 necessario copiarlo.
742
743 La seconda funzione, \funcd{psignal}, deriva da BSD ed è analoga alla funzione
744 \func{perror} descritta sempre in sez.~\ref{sec:sys_strerror}; il suo prototipo
745 è:
746 \begin{prototype}{signal.h}{void psignal(int sig, const char *s)} 
747   Stampa sullo standard error un messaggio costituito dalla stringa \param{s},
748   seguita da due punti ed una descrizione del segnale indicato da \param{sig}.
749 \end{prototype}
750
751 Una modalità alternativa per utilizzare le descrizioni restituite da
752 \func{strsignal} e \func{psignal} è quello di usare la variabile
753 \var{sys\_siglist}, che è definita in \file{signal.h} e può essere acceduta
754 con la dichiarazione:
755 \includecodesnip{listati/siglist.c}
756
757 L'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
758 indicizzate per numero di segnale, per cui una chiamata del tipo di \code{char
759   *decr = strsignal(SIGINT)} può essere sostituita dall'equivalente \code{char
760   *decr = sys\_siglist[SIGINT]}.
761
762
763
764 \section{La gestione dei segnali}
765 \label{sec:sig_management}
766
767 I segnali sono il primo e più classico esempio di eventi asincroni, cioè di
768 eventi che possono accadere in un qualunque momento durante l'esecuzione di un
769 programma. Per questa loro caratteristica la loro gestione non può essere
770 effettuata all'interno del normale flusso di esecuzione dello stesso, ma è
771 delegata appunto agli eventuali gestori che si sono installati.
772
773 In questa sezione vedremo come si effettua la gestione dei segnali, a partire
774 dalla loro interazione con le system call, passando per le varie funzioni che
775 permettono di installare i gestori e controllare le reazioni di un processo
776 alla loro occorrenza.
777
778
779 \subsection{Il comportamento generale del sistema}
780 \label{sec:sig_gen_beha}
781
782 Abbiamo già trattato in sez.~\ref{sec:sig_intro} le modalità con cui il sistema
783 gestisce l'interazione fra segnali e processi, ci resta da esaminare però il
784 comportamento delle system call; in particolare due di esse, \func{fork} ed
785 \func{exec}, dovranno essere prese esplicitamente in considerazione, data la
786 loro stretta relazione con la creazione di nuovi processi.
787
788 Come accennato in sez.~\ref{sec:proc_fork} quando viene creato un nuovo
789 processo esso eredita dal padre sia le azioni che sono state impostate per i
790 singoli segnali, che la maschera dei segnali bloccati (vedi
791 sez.~\ref{sec:sig_sigmask}).  Invece tutti i segnali pendenti e gli allarmi
792 vengono cancellati; essi infatti devono essere recapitati solo al padre, al
793 figlio dovranno arrivare solo i segnali dovuti alle sue azioni.
794
795 Quando si mette in esecuzione un nuovo programma con \func{exec} (si ricordi
796 quanto detto in sez.~\ref{sec:proc_exec}) tutti i segnali per i quali è stato
797 installato un gestore vengono reimpostati a \const{SIG\_DFL}. Non ha più
798 senso infatti fare riferimento a funzioni definite nel programma originario,
799 che non sono presenti nello spazio di indirizzi del nuovo programma.
800
801 Si noti che questo vale solo per le azioni per le quali è stato installato un
802 gestore; viene mantenuto invece ogni eventuale impostazione dell'azione a
803 \const{SIG\_IGN}. Questo permette ad esempio alla shell di impostare ad
804 \const{SIG\_IGN} le risposte per \const{SIGINT} e \const{SIGQUIT} per i
805 programmi eseguiti in background, che altrimenti sarebbero interrotti da una
806 successiva pressione di \texttt{C-c} o \texttt{C-y}.
807
808 Per quanto riguarda il comportamento di tutte le altre system call si danno
809 sostanzialmente due casi, a seconda che esse siano \index{system~call~lente}
810 \textsl{lente} (\textit{slow}) o \textsl{veloci} (\textit{fast}). La gran
811 parte di esse appartiene a quest'ultima categoria, che non è influenzata
812 dall'arrivo di un segnale. Esse sono dette \textsl{veloci} in quanto la loro
813 esecuzione è sostanzialmente immediata; la risposta al segnale viene sempre
814 data dopo che la system call è stata completata, in quanto attendere per
815 eseguire un gestore non comporta nessun inconveniente.
816
817 In alcuni casi però alcune system call (che per questo motivo vengono chiamate
818 \textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può
819 attendere la conclusione della system call, perché questo renderebbe
820 impossibile una risposta pronta al segnale, per cui il gestore viene
821 eseguito prima che la system call sia ritornata.  Un elenco dei casi in cui si
822 presenta questa situazione è il seguente:
823 \begin{itemize*}
824 \item la lettura da file che possono bloccarsi in attesa di dati non ancora
825   presenti (come per certi \index{file!di~dispositivo} file di dispositivo, i
826   socket o le pipe);
827 \item la scrittura sugli stessi file, nel caso in cui dati non possano essere
828   accettati immediatamente (di nuovo comune per i socket);
829 \item l'apertura di un file di dispositivo che richiede operazioni non
830   immediate per una risposta (ad esempio l'apertura di un nastro che deve
831   essere riavvolto);
832 \item le operazioni eseguite con \func{ioctl} che non è detto possano essere
833   eseguite immediatamente;
834 \item le funzioni di intercomunicazione che si bloccano in attesa di risposte
835   da altri processi;
836 \item la funzione \func{pause} (usata appunto per attendere l'arrivo di un
837   segnale);
838 \item la funzione \func{wait} (se nessun processo figlio è ancora terminato).
839 \end{itemize*}
840
841 In questo caso si pone il problema di cosa fare una volta che il gestore sia
842 ritornato. La scelta originaria dei primi Unix era quella di far ritornare
843 anche la system call restituendo l'errore di \errcode{EINTR}. Questa è a
844 tutt'oggi una scelta corrente, ma comporta che i programmi che usano dei
845 gestori controllino lo stato di uscita delle funzioni che eseguono una system
846 call lenta per ripeterne la chiamata qualora l'errore fosse questo.
847
848 Dimenticarsi di richiamare una system call interrotta da un segnale è un
849 errore comune, tanto che le \acr{glibc} provvedono una macro
850 \code{TEMP\_FAILURE\_RETRY(expr)} che esegue l'operazione automaticamente,
851 ripetendo l'esecuzione dell'espressione \var{expr} fintanto che il risultato
852 non è diverso dall'uscita con un errore \errcode{EINTR}.
853
854 La soluzione è comunque poco elegante e BSD ha scelto un approccio molto
855 diverso, che è quello di fare ripartire automaticamente una system call
856 interrotta invece di farla fallire. In questo caso ovviamente non c'è bisogno
857 di preoccuparsi di controllare il codice di errore; si perde però la
858 possibilità di eseguire azioni specifiche all'occorrenza di questa particolare
859 condizione.
860
861 Linux e le \acr{glibc} consentono di utilizzare entrambi gli approcci,
862 attraverso una opportuna opzione di \func{sigaction} (vedi
863 sez.~\ref{sec:sig_sigaction}). È da chiarire comunque che nel caso di
864 interruzione nel mezzo di un trasferimento parziale di dati, le system call
865 ritornano sempre indicando i byte trasferiti.
866
867
868 \subsection{La funzione \func{signal}}
869 \label{sec:sig_signal}
870
871 L'interfaccia più semplice per la gestione dei segnali è costituita dalla
872 funzione \funcd{signal} che è definita fin dallo standard ANSI C.
873 Quest'ultimo però non considera sistemi multitasking, per cui la definizione è
874 tanto vaga da essere del tutto inutile in un sistema Unix; è questo il motivo
875 per cui ogni implementazione successiva ne ha modificato e ridefinito il
876 comportamento, pur mantenendone immutato il prototipo\footnote{in realtà in
877   alcune vecchie implementazioni (SVr4 e 4.3+BSD in particolare) vengono usati
878   alcuni argomenti aggiuntivi per definire il comportamento della funzione,
879   vedremo in sez.~\ref{sec:sig_sigaction} che questo è possibile usando la
880   funzione \func{sigaction}.}  che è:
881 \begin{prototype}{signal.h}
882   {sighandler\_t signal(int signum, sighandler\_t handler)} 
883   
884   Installa la funzione di gestione \param{handler} (il gestore) per il
885   segnale \param{signum}.
886   
887   \bodydesc{La funzione ritorna il precedente gestore in caso di successo
888     o \const{SIG\_ERR} in caso di errore.}
889 \end{prototype}
890
891 In questa definizione si è usato un tipo di dato, \type{sighandler\_t}, che è
892 una estensione GNU, definita dalle \acr{glibc}, che permette di riscrivere il
893 prototipo di \func{signal} nella forma appena vista, molto più leggibile di
894 quanto non sia la versione originaria, che di norma è definita come:
895 \includecodesnip{listati/signal.c}
896 questa infatti, per la poca chiarezza della sintassi del C quando si vanno a
897 trattare puntatori a funzioni, è molto meno comprensibile.  Da un confronto
898 con il precedente prototipo si può dedurre la definizione di
899 \type{sighandler\_t} che è:
900 \includecodesnip{listati/sighandler_t.c}
901 e cioè un puntatore ad una funzione \ctyp{void} (cioè senza valore di ritorno)
902 e che prende un argomento di tipo \ctyp{int}.\footnote{si devono usare le
903   parentesi intorno al nome della funzione per via delle precedenze degli
904   operatori del C, senza di esse si sarebbe definita una funzione che ritorna
905   un puntatore a \ctyp{void} e non un puntatore ad una funzione \ctyp{void}.}
906 La funzione \func{signal} quindi restituisce e prende come secondo argomento
907 un puntatore a una funzione di questo tipo, che è appunto la funzione che
908 verrà usata come gestore del segnale.
909
910 Il numero di segnale passato nell'argomento \param{signum} può essere indicato
911 direttamente con una delle costanti definite in sez.~\ref{sec:sig_standard}.
912 L'argomento \param{handler} che indica il gestore invece, oltre all'indirizzo
913 della funzione da chiamare all'occorrenza del segnale, può assumere anche i
914 due valori costanti \const{SIG\_IGN} e \const{SIG\_DFL}; il primo indica che
915 il segnale deve essere ignorato,\footnote{si ricordi però che i due segnali
916   \const{SIGKILL} e \const{SIGSTOP} non possono essere né ignorati né
917   intercettati; l'uso di \const{SIG\_IGN} per questi segnali non ha alcun
918   effetto.} mentre il secondo ripristina l'azione predefinita.\footnote{e
919   serve a tornare al comportamento di default quando non si intende più
920   gestire direttamente un segnale.}
921
922 La funzione restituisce l'indirizzo dell'azione precedente, che può essere
923 salvato per poterlo ripristinare (con un'altra chiamata a \func{signal}) in un
924 secondo tempo. Si ricordi che se si imposta come azione \const{SIG\_IGN} (o si
925 imposta un \const{SIG\_DFL} per un segnale la cui azione predefinita è di
926 essere ignorato), tutti i segnali pendenti saranno scartati, e non verranno
927 mai notificati.
928
929 L'uso di \func{signal} è soggetto a problemi di compatibilità, dato che essa
930 si comporta in maniera diversa per sistemi derivati da BSD o da System V. In
931 questi ultimi infatti la funzione è conforme al comportamento originale dei
932 primi Unix in cui il gestore viene disinstallato alla sua chiamata, secondo la
933 semantica inaffidabile; anche Linux seguiva questa convenzione con le vecchie
934 librerie del C come le \acr{libc4} e le \acr{libc5}.\footnote{nelle
935   \acr{libc5} esiste però la possibilità di includere \file{bsd/signal.h} al
936   posto di \file{signal.h}, nel qual caso la funzione \func{signal} viene
937   ridefinita per seguire la semantica affidabile usata da BSD.}
938
939 Al contrario BSD segue la semantica affidabile, non disinstallando il gestore
940 e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo delle
941 \acr{glibc} dalla versione 2 anche Linux è passato a questo comportamento.  Il
942 comportamento della versione originale della funzione, il cui uso è deprecato
943 per i motivi visti in sez.~\ref{sec:sig_semantics}, può essere ottenuto
944 chiamando \func{sysv\_signal}, una volta che si sia definita la macro
945 \macro{\_XOPEN\_SOURCE}.  In generale, per evitare questi problemi, l'uso di
946 \func{signal} (ed ogni eventuale ridefinizione della stessa) è da evitare;
947 tutti i nuovi programmi dovrebbero usare \func{sigaction}.
948
949 È da tenere presente che, seguendo lo standard POSIX, il comportamento di un
950 processo che ignora i segnali \const{SIGFPE}, \const{SIGILL}, o
951 \const{SIGSEGV} (qualora questi non originino da una chiamata ad una
952 \func{kill} o ad una \func{raise}) è indefinito. Un gestore che ritorna da
953 questi segnali può dare luogo ad un ciclo infinito.
954
955
956 \subsection{Le funzioni \func{kill} e \func{raise}}
957 \label{sec:sig_kill_raise}
958
959 Come precedentemente accennato in sez.~\ref{sec:sig_types}, un segnale può
960 anche essere generato direttamente nell'esecuzione di un programma, attraverso
961 la chiamata ad una opportuna system call. Le funzioni che si utilizzano di
962 solito per inviare un segnale generico ad un processo sono due: \func{raise} e
963 \func{kill}.
964
965 La prima funzione è \funcd{raise}, che è definita dallo standard ANSI C, e
966 serve per inviare un segnale al processo corrente,\footnote{non prevedendo la
967   presenza di un sistema multiutente lo standard ANSI C non poteva che
968   definire una funzione che invia il segnale al programma in esecuzione. Nel
969   caso di Linux questa viene implementata come funzione di compatibilità.}  il
970 suo prototipo è:
971 \begin{prototype}{signal.h}{int raise(int sig)}
972   Invia il segnale \param{sig} al processo corrente.
973   
974   \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
975     errore, il solo errore restituito è \errval{EINVAL} qualora si sia
976     specificato un numero di segnale invalido.}
977 \end{prototype}
978
979 Il valore di \param{sig} specifica il segnale che si vuole inviare e può
980 essere specificato con una delle macro definite in
981 sez.~\ref{sec:sig_classification}.  In genere questa funzione viene usata per
982 riprodurre il comportamento predefinito di un segnale che sia stato
983 intercettato. In questo caso, una volta eseguite le operazioni volute, il
984 gestore dovrà prima reinstallare l'azione predefinita, per poi attivarla
985 chiamando \func{raise}.
986
987 Mentre \func{raise} è una funzione di libreria, quando si vuole inviare un
988 segnale generico ad un processo occorre utilizzare la apposita system call,
989 questa può essere chiamata attraverso la funzione \funcd{kill}, il cui
990 prototipo è:
991 \begin{functions}
992   \headdecl{sys/types.h}
993   \headdecl{signal.h}
994   \funcdecl{int kill(pid\_t pid, int sig)} Invia il segnale \param{sig} al
995   processo specificato con \param{pid}.
996   
997   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
998     errore nel qual caso \var{errno} assumerà uno dei valori:
999     \begin{errlist}
1000     \item[\errcode{EINVAL}] Il segnale specificato non esiste.
1001     \item[\errcode{ESRCH}] Il processo selezionato non esiste.
1002     \item[\errcode{EPERM}] Non si hanno privilegi sufficienti ad inviare il
1003       segnale.
1004     \end{errlist}}
1005 \end{functions}
1006
1007 Lo standard POSIX prevede che il valore 0 per \param{sig} sia usato per
1008 specificare il segnale nullo.  Se la funzione viene chiamata con questo valore
1009 non viene inviato nessun segnale, ma viene eseguito il controllo degli errori,
1010 in tal caso si otterrà un errore \errcode{EPERM} se non si hanno i permessi
1011 necessari ed un errore \errcode{ESRCH} se il processo specificato non esiste.
1012 Si tenga conto però che il sistema ricicla i \acr{pid} (come accennato in
1013 sez.~\ref{sec:proc_pid}) per cui l'esistenza di un processo non significa che
1014 esso sia realmente quello a cui si intendeva mandare il segnale.
1015
1016 Il valore dell'argomento \param{pid} specifica il processo (o i processi) di
1017 destinazione a cui il segnale deve essere inviato e può assumere i valori
1018 riportati in tab.~\ref{tab:sig_kill_values}.
1019
1020 Si noti pertanto che la funzione \code{raise(sig)} può essere definita in
1021 termini di \func{kill}, ed è sostanzialmente equivalente ad una
1022 \code{kill(getpid(), sig)}. Siccome \func{raise}, che è definita nello
1023 standard ISO C, non esiste in alcune vecchie versioni di Unix, in generale
1024 l'uso di \func{kill} finisce per essere più portabile.
1025
1026 Una seconda funzione che può essere definita in termini di \func{kill} è
1027 \funcd{killpg}, che è sostanzialmente equivalente a
1028 \code{kill(-pidgrp, signal)}; il suo prototipo è:
1029 \begin{prototype}{signal.h}{int killpg(pid\_t pidgrp, int signal)} 
1030   
1031   Invia il segnale \param{signal} al \itindex{process~group} \textit{process
1032     group} \param{pidgrp}.
1033
1034   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
1035     errore, gli errori sono gli stessi di \func{kill}.}
1036 \end{prototype}
1037 \noindent e permette di inviare un segnale a tutto un \itindex{process~group}
1038 \textit{process group} (vedi sez.~\ref{sec:sess_proc_group}).
1039
1040 \begin{table}[htb]
1041   \footnotesize
1042   \centering
1043   \begin{tabular}[c]{|r|l|}
1044     \hline
1045     \textbf{Valore} & \textbf{Significato} \\
1046     \hline
1047     \hline
1048     $>0$ & il segnale è mandato al processo con il \acr{pid} indicato.\\
1049     0    & il segnale è mandato ad ogni processo del \itindex{process~group}
1050            \textit{process group} del chiamante.\\ 
1051     $-1$ & il segnale è mandato ad ogni processo (eccetto \cmd{init}).\\
1052     $<-1$ & il segnale è mandato ad ogni processo del \textit{process group} 
1053             \itindex{process~group} $|\code{pid}|$.\\
1054     \hline
1055   \end{tabular}
1056   \caption{Valori dell'argomento \param{pid} per la funzione
1057     \func{kill}.}
1058   \label{tab:sig_kill_values}
1059 \end{table}
1060
1061 Solo l'amministratore può inviare un segnale ad un processo qualunque, in
1062 tutti gli altri casi l'user-ID reale o l'user-ID effettivo del processo
1063 chiamante devono corrispondere all'user-ID reale o all'user-ID salvato della
1064 destinazione. Fa eccezione il caso in cui il segnale inviato sia
1065 \const{SIGCONT}, nel quale occorre che entrambi i processi appartengano alla
1066 stessa sessione. Inoltre, dato il ruolo fondamentale che riveste nel sistema
1067 (si ricordi quanto visto in sez.~\ref{sec:sig_termination}), non è possibile
1068 inviare al processo 1 (cioè a \cmd{init}) segnali per i quali esso non abbia
1069 un gestore installato.
1070
1071 Infine, seguendo le specifiche POSIX 1003.1-2001, l'uso della chiamata
1072 \code{kill(-1, sig)} comporta che il segnale sia inviato (con la solita
1073 eccezione di \cmd{init}) a tutti i processi per i quali i permessi lo
1074 consentano. Lo standard permette comunque alle varie implementazioni di
1075 escludere alcuni processi specifici: nel caso in questione Linux non invia il
1076 segnale al processo che ha effettuato la chiamata.
1077
1078
1079 \subsection{Le funzioni \func{alarm} e \func{abort}}
1080 \label{sec:sig_alarm_abort}
1081
1082 Un caso particolare di segnali generati a richiesta è quello che riguarda i
1083 vari segnali di temporizzazione e \const{SIGABRT}, per ciascuno di questi
1084 segnali sono previste funzioni specifiche che ne effettuino l'invio. La più
1085 comune delle funzioni usate per la temporizzazione è \funcd{alarm} il cui
1086 prototipo è:
1087 \begin{prototype}{unistd.h}{unsigned int alarm(unsigned int seconds)}
1088   Predispone l'invio di \const{SIGALRM} dopo \param{seconds} secondi.
1089   
1090   \bodydesc{La funzione restituisce il numero di secondi rimanenti ad un
1091     precedente allarme, o zero se non c'erano allarmi pendenti.}
1092 \end{prototype}
1093
1094 La funzione fornisce un meccanismo che consente ad un processo di predisporre
1095 un'interruzione nel futuro, (ad esempio per effettuare una qualche operazione
1096 dopo un certo periodo di tempo), programmando l'emissione di un segnale (nel
1097 caso in questione \const{SIGALRM}) dopo il numero di secondi specificato da
1098 \param{seconds}.
1099
1100 Se si specifica per \param{seconds} un valore nullo non verrà inviato nessun
1101 segnale; siccome alla chiamata viene cancellato ogni precedente allarme,
1102 questo può essere usato per cancellare una programmazione precedente. 
1103
1104 La funzione inoltre ritorna il numero di secondi rimanenti all'invio
1105 dell'allarme programmato in precedenza. In questo modo è possibile controllare
1106 se non si è cancellato un precedente allarme e predisporre eventuali misure
1107 che permettano di gestire il caso in cui servono più interruzioni.
1108
1109 In sez.~\ref{sec:sys_unix_time} abbiamo visto che ad ogni processo sono
1110 associati tre tempi diversi: il \textit{clock time}, l'\textit{user time} ed
1111 il \textit{system time}.  Per poterli calcolare il kernel mantiene per ciascun
1112 processo tre diversi timer:
1113 \begin{itemize}
1114 \item un \textit{real-time timer} che calcola il tempo reale trascorso (che
1115   corrisponde al \textit{clock time}). La scadenza di questo timer provoca
1116   l'emissione di \const{SIGALRM};
1117 \item un \textit{virtual timer} che calcola il tempo di processore usato dal
1118   processo in user space (che corrisponde all'\textit{user time}). La scadenza
1119   di questo timer provoca l'emissione di \const{SIGVTALRM};
1120 \item un \textit{profiling timer} che calcola la somma dei tempi di processore
1121   utilizzati direttamente dal processo in user space, e dal kernel nelle
1122   system call ad esso relative (che corrisponde a quello che in
1123   sez.~\ref{sec:sys_unix_time} abbiamo chiamato \textit{CPU time}). La scadenza
1124   di questo timer provoca l'emissione di \const{SIGPROF}.
1125 \end{itemize}
1126
1127 Il timer usato da \func{alarm} è il \textit{clock time}, e corrisponde cioè al
1128 tempo reale. La funzione come abbiamo visto è molto semplice, ma proprio per
1129 questo presenta numerosi limiti: non consente di usare gli altri timer, non
1130 può specificare intervalli di tempo con precisione maggiore del secondo e
1131 genera il segnale una sola volta.
1132
1133 Per ovviare a questi limiti Linux deriva da BSD la funzione \funcd{setitimer}
1134 che permette di usare un timer qualunque e l'invio di segnali periodici, al
1135 costo però di una maggiore complessità d'uso e di una minore portabilità. Il
1136 suo prototipo è:
1137 \begin{prototype}{sys/time.h}{int setitimer(int which, const struct
1138     itimerval *value, struct itimerval *ovalue)} 
1139   
1140   Predispone l'invio di un segnale di allarme alla scadenza dell'intervallo
1141   \param{value} sul timer specificato da \param{which}.
1142   
1143   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
1144     errore, nel qual caso \var{errno} assumerà uno dei valori \errval{EINVAL} o
1145     \errval{EFAULT}.}
1146 \end{prototype}
1147
1148 Il valore di \param{which} permette di specificare quale dei tre timer
1149 illustrati in precedenza usare; i possibili valori sono riportati in
1150 tab.~\ref{tab:sig_setitimer_values}.
1151 \begin{table}[htb]
1152   \footnotesize
1153   \centering
1154   \begin{tabular}[c]{|l|l|}
1155     \hline
1156     \textbf{Valore} & \textbf{Timer} \\
1157     \hline
1158     \hline
1159     \const{ITIMER\_REAL}    & \textit{real-time timer}\\
1160     \const{ITIMER\_VIRTUAL} & \textit{virtual timer}\\
1161     \const{ITIMER\_PROF}    & \textit{profiling timer}\\
1162     \hline
1163   \end{tabular}
1164   \caption{Valori dell'argomento \param{which} per la funzione
1165     \func{setitimer}.}
1166   \label{tab:sig_setitimer_values}
1167 \end{table}
1168
1169 Il valore della struttura specificata \param{value} viene usato per impostare
1170 il timer, se il puntatore \param{ovalue} non è nullo il precedente valore
1171 viene salvato qui. I valori dei timer devono essere indicati attraverso una
1172 struttura \struct{itimerval}, definita in fig.~\ref{fig:file_stat_struct}.
1173
1174 La struttura è composta da due membri, il primo, \var{it\_interval} definisce
1175 il periodo del timer; il secondo, \var{it\_value} il tempo mancante alla
1176 scadenza. Entrambi esprimono i tempi tramite una struttura \struct{timeval} che
1177 permette una precisione fino al microsecondo.
1178
1179 Ciascun timer decrementa il valore di \var{it\_value} fino a zero, poi invia
1180 il segnale e reimposta \var{it\_value} al valore di \var{it\_interval}, in
1181 questo modo il ciclo verrà ripetuto; se invece il valore di \var{it\_interval}
1182 è nullo il timer si ferma.
1183
1184 \begin{figure}[!htb]
1185   \footnotesize \centering
1186   \begin{minipage}[c]{15cm}
1187     \includestruct{listati/itimerval.h}
1188   \end{minipage} 
1189   \normalsize 
1190   \caption{La struttura \structd{itimerval}, che definisce i valori dei timer
1191     di sistema.}
1192   \label{fig:sig_itimerval}
1193 \end{figure}
1194
1195 L'uso di \func{setitimer} consente dunque un controllo completo di tutte le
1196 caratteristiche dei timer, ed in effetti la stessa \func{alarm}, benché
1197 definita direttamente nello standard POSIX.1, può a sua volta essere espressa
1198 in termini di \func{setitimer}, come evidenziato dal manuale delle \acr{glibc}
1199 \cite{glibc} che ne riporta la definizione mostrata in
1200 fig.~\ref{fig:sig_alarm_def}.
1201
1202 \begin{figure}[!htb]
1203   \footnotesize \centering
1204   \begin{minipage}[c]{15cm}
1205     \includestruct{listati/alarm_def.c}
1206   \end{minipage} 
1207   \normalsize 
1208   \caption{Definizione di \func{alarm} in termini di \func{setitimer}.} 
1209   \label{fig:sig_alarm_def}
1210 \end{figure}
1211
1212 Si deve comunque tenere presente che la precisione di queste funzioni è
1213 limitata da quella della frequenza del timer di sistema (che nel caso dei PC
1214 significa circa 10~ms). Il sistema assicura comunque che il segnale non sarà
1215 mai generato prima della scadenza programmata (l'arrotondamento cioè è sempre
1216 effettuato per eccesso).  
1217
1218 Una seconda causa di potenziali ritardi è che il segnale viene generato alla
1219 scadenza del timer, ma poi deve essere consegnato al processo; se quest'ultimo
1220 è attivo (questo è sempre vero per \const{ITIMER\_VIRT}) la consegna è
1221 immediata, altrimenti può esserci un ulteriore ritardo che può variare a
1222 seconda del carico del sistema.
1223
1224 Questo ha una conseguenza che può indurre ad errori molto subdoli, si tenga
1225 conto poi che in caso di sistema molto carico, si può avere il caso patologico
1226 in cui un timer scade prima che il segnale di una precedente scadenza sia
1227 stato consegnato; in questo caso, per il comportamento dei segnali descritto
1228 in sez.~\ref{sec:sig_sigchld}, un solo segnale sarà consegnato.
1229
1230
1231 Dato che sia \func{alarm} che \func{setitimer} non consentono di leggere il
1232 valore corrente di un timer senza modificarlo, è possibile usare la funzione
1233 \funcd{getitimer}, il cui prototipo è:
1234 \begin{prototype}{sys/time.h}{int getitimer(int which, struct
1235     itimerval *value)}
1236   
1237   Legge in \param{value} il valore del timer specificato da \param{which}.
1238   
1239   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
1240     errore e restituisce gli stessi errori di \func{getitimer}}
1241 \end{prototype}
1242 \noindent i cui argomenti hanno lo stesso significato e formato di quelli di
1243 \func{setitimer}. 
1244
1245
1246 L'ultima funzione che permette l'invio diretto di un segnale è \funcd{abort},
1247 che, come accennato in sez.~\ref{sec:proc_termination}, permette di abortire
1248 l'esecuzione di un programma tramite l'invio di \const{SIGABRT}. Il suo
1249 prototipo è:
1250 \begin{prototype}{stdlib.h}{void abort(void)}
1251   
1252   Abortisce il processo corrente.
1253   
1254   \bodydesc{La funzione non ritorna, il processo è terminato inviando il
1255   segnale di \const{SIGABRT}.}
1256 \end{prototype}
1257
1258 La differenza fra questa funzione e l'uso di \func{raise} è che anche se il
1259 segnale è bloccato o ignorato, la funzione ha effetto lo stesso. Il segnale
1260 può però essere intercettato per effettuare eventuali operazioni di chiusura
1261 prima della terminazione del processo.
1262
1263 Lo standard ANSI C richiede inoltre che anche se il gestore ritorna, la
1264 funzione non ritorni comunque. Lo standard POSIX.1 va oltre e richiede che se
1265 il processo non viene terminato direttamente dal gestore sia la stessa
1266 \func{abort} a farlo al ritorno dello stesso. Inoltre, sempre seguendo lo
1267 standard POSIX, prima della terminazione tutti i file aperti e gli stream
1268 saranno chiusi ed i buffer scaricati su disco. Non verranno invece eseguite le
1269 eventuali funzioni registrate con \func{atexit} e \func{on\_exit}.
1270
1271
1272 \subsection{Le funzioni di pausa e attesa}
1273 \label{sec:sig_pause_sleep}
1274
1275 Sono parecchie le occasioni in cui si può avere necessità di sospendere
1276 temporaneamente l'esecuzione di un processo. Nei sistemi più elementari in
1277 genere questo veniva fatto con un opportuno loop di attesa, ma in un sistema
1278 multitasking un loop di attesa è solo un inutile spreco di CPU, per questo ci
1279 sono apposite funzioni che permettono di mettere un processo in stato di
1280 attesa.\footnote{si tratta in sostanza di funzioni che permettono di portare
1281   esplicitamente il processo in stato di \textit{sleep}, vedi
1282   sez.~\ref{sec:proc_sched}.}
1283
1284 Il metodo tradizionale per fare attendere ad un processo fino all'arrivo di un
1285 segnale è quello di usare la funzione \funcd{pause}, il cui prototipo è:
1286 \begin{prototype}{unistd.h}{int pause(void)}
1287   
1288   Pone il processo in stato di sleep fino al ritorno di un gestore.
1289   
1290   \bodydesc{La funzione ritorna solo dopo che un segnale è stato ricevuto ed
1291     il relativo gestore è ritornato, nel qual caso restituisce $-1$ e
1292     \var{errno} assumerà il valore \errval{EINTR}.}
1293 \end{prototype}
1294
1295 La funzione segnala sempre una condizione di errore (il successo sarebbe
1296 quello di aspettare indefinitamente). In genere si usa questa funzione quando
1297 si vuole mettere un processo in attesa di un qualche evento specifico che non
1298 è sotto il suo diretto controllo (ad esempio la si può usare per interrompere
1299 l'esecuzione del processo fino all'arrivo di un segnale inviato da un altro
1300 processo).
1301
1302 Quando invece si vuole fare attendere un processo per un intervallo di tempo
1303 già noto nello standard POSIX.1 viene definita la funzione \funcd{sleep}, il
1304 cui prototipo è:
1305 \begin{prototype}{unistd.h}{unsigned int sleep(unsigned int seconds)}
1306   
1307   Pone il processo in stato di sleep per \param{seconds} secondi.
1308   
1309   \bodydesc{La funzione restituisce zero se l'attesa viene completata, o il
1310   numero di secondi restanti se viene interrotta da un segnale.}
1311 \end{prototype}
1312
1313 La funzione attende per il tempo specificato, a meno di non essere interrotta
1314 da un segnale. In questo caso non è una buona idea ripetere la chiamata per il
1315 tempo rimanente, in quanto la riattivazione del processo può avvenire in un
1316 qualunque momento, ma il valore restituito sarà sempre arrotondato al secondo,
1317 con la conseguenza che, se la successione dei segnali è particolarmente
1318 sfortunata e le differenze si accumulano, si potranno avere ritardi anche di
1319 parecchi secondi. In genere la scelta più sicura è quella di stabilire un
1320 termine per l'attesa, e ricalcolare tutte le volte il numero di secondi da
1321 aspettare.
1322
1323 In alcune implementazioni inoltre l'uso di \func{sleep} può avere conflitti
1324 con quello di \const{SIGALRM}, dato che la funzione può essere realizzata con
1325 l'uso di \func{pause} e \func{alarm} (in maniera analoga all'esempio che
1326 vedremo in sez.~\ref{sec:sig_example}). In tal caso mescolare chiamata di
1327 \func{alarm} e \func{sleep} o modificare l'azione di \const{SIGALRM}, può
1328 causare risultati indefiniti. Nel caso delle \acr{glibc} è stata usata una
1329 implementazione completamente indipendente e questi problemi non ci sono.
1330
1331 La granularità di \func{sleep} permette di specificare attese soltanto in
1332 secondi, per questo sia sotto BSD4.3 che in SUSv2 è stata definita la funzione
1333 \funcd{usleep} (dove la \texttt{u} è intesa come sostituzione di $\mu$); i due
1334 standard hanno delle definizioni diverse, ma le \acr{glibc}
1335 seguono\footnote{secondo la pagina di manuale almeno dalla versione 2.2.2.}
1336 seguono quella di SUSv2 che prevede il seguente prototipo:
1337 \begin{prototype}{unistd.h}{int usleep(unsigned long usec)}
1338   
1339   Pone il processo in stato di sleep per \param{usec} microsecondi.
1340   
1341   \bodydesc{La funzione restituisce zero se l'attesa viene completata, o $-1$
1342     in caso di errore, nel qual caso \var{errno} assumerà il valore
1343     \errval{EINTR}.}
1344
1345 \end{prototype}
1346
1347 Anche questa funzione, a seconda delle implementazioni, può presentare
1348 problemi nell'interazione con \func{alarm} e \const{SIGALRM}. È pertanto
1349 deprecata in favore della funzione \funcd{nanosleep}, definita dallo standard
1350 POSIX1.b, il cui prototipo è:
1351 \begin{prototype}{unistd.h}{int nanosleep(const struct timespec *req, struct
1352     timespec *rem)}
1353   
1354   Pone il processo in stato di sleep per il tempo specificato da \param{req}.
1355   In caso di interruzione restituisce il tempo restante in \param{rem}.
1356   
1357   \bodydesc{La funzione restituisce zero se l'attesa viene completata, o $-1$
1358     in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
1359     \begin{errlist}
1360     \item[\errcode{EINVAL}] si è specificato un numero di secondi negativo o un
1361       numero di nanosecondi maggiore di 999.999.999.
1362     \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
1363     \end{errlist}}
1364 \end{prototype}
1365
1366 Lo standard richiede che la funzione sia implementata in maniera del tutto
1367 indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto
1368   utilizzando direttamente il timer del kernel.} e sia utilizzabile senza
1369 interferenze con l'uso di \const{SIGALRM}. La funzione prende come argomenti
1370 delle strutture di tipo \struct{timespec}, la cui definizione è riportata in
1371 fig.~\ref{fig:sys_timeval_struct}, che permettono di specificare un tempo con
1372 una precisione (teorica) fino al nanosecondo.
1373
1374 La funzione risolve anche il problema di proseguire l'attesa dopo
1375 l'interruzione dovuta ad un segnale; infatti in tal caso in \param{rem} viene
1376 restituito il tempo rimanente rispetto a quanto richiesto inizialmente, e
1377 basta richiamare la funzione per completare l'attesa. 
1378
1379 Chiaramente, anche se il tempo può essere specificato con risoluzioni fino al
1380 nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
1381 temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
1382 specificato, ma prima che il processo possa tornare ad essere eseguito
1383 occorrerà almeno attendere il successivo giro di \itindex{scheduler} scheduler
1384 e cioè un tempo che a seconda dei casi può arrivare fino a 1/\const{HZ},
1385 (sempre che il sistema sia scarico ed il processa venga immediatamente rimesso
1386 in esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
1387 arrotondato al multiplo successivo di 1/\const{HZ}.
1388
1389 In realtà è possibile ottenere anche pause più precise del centesimo di
1390 secondo usando politiche di \itindex{scheduler} scheduling real-time come
1391 \const{SCHED\_FIFO} o \const{SCHED\_RR}; in tal caso infatti il meccanismo di
1392 \itindex{scheduler} scheduling ordinario viene evitato, e si raggiungono pause
1393 fino ai 2~ms con precisioni del $\mu$s.
1394
1395
1396
1397 \subsection{Un esempio elementare}
1398 \label{sec:sig_sigchld}
1399
1400 Un semplice esempio per illustrare il funzionamento di un gestore di segnale è
1401 quello della gestione di \const{SIGCHLD}. Abbiamo visto in
1402 sez.~\ref{sec:proc_termination} che una delle azioni eseguite dal kernel alla
1403 conclusione di un processo è quella di inviare questo segnale al
1404 padre.\footnote{in realtà in SVr4 eredita la semantica di System V, in cui il
1405   segnale si chiama \const{SIGCLD} e viene trattato in maniera speciale; in
1406   System V infatti se si imposta esplicitamente l'azione a \const{SIG\_IGN} il
1407   segnale non viene generato ed il sistema non genera \index{zombie} zombie
1408   (lo stato di terminazione viene scartato senza dover chiamare una
1409   \func{wait}).  L'azione predefinita è sempre quella di ignorare il segnale,
1410   ma non attiva questo comportamento. Linux, come BSD e POSIX, non supporta
1411   questa semantica ed usa il nome di \const{SIGCLD} come sinonimo di
1412   \const{SIGCHLD}.} In generale dunque, quando non interessa elaborare lo
1413 stato di uscita di un processo, si può completare la gestione della
1414 terminazione installando un gestore per \const{SIGCHLD} il cui unico compito
1415 sia quello di chiamare \func{waitpid} per completare la procedura di
1416 terminazione in modo da evitare la formazione di \index{zombie} zombie.
1417
1418 In fig.~\ref{fig:sig_sigchld_handl} è mostrato il codice contenente una
1419 implementazione generica di una funzione di gestione per \const{SIGCHLD}, (che
1420 si trova nei sorgenti allegati nel file \file{SigHand.c}); se ripetiamo i test
1421 di sez.~\ref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione
1422 \cmd{-s} (che si limita ad effettuare l'installazione di questa funzione come
1423 gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione
1424 di \index{zombie} zombie.
1425
1426 \begin{figure}[!htb]
1427   \footnotesize  \centering
1428   \begin{minipage}[c]{15cm}
1429     \includecodesample{listati/hand_sigchild.c}
1430   \end{minipage}
1431   \normalsize 
1432   \caption{Codice di una funzione generica di gestione per il segnale
1433     \texttt{SIGCHLD}.}
1434   \label{fig:sig_sigchld_handl}
1435 \end{figure}
1436
1437 Il codice del gestore è di lettura immediata; come buona norma di
1438 programmazione (si ricordi quanto accennato sez.~\ref{sec:sys_errno}) si
1439 comincia (\texttt{\small 6--7}) con il salvare lo stato corrente di
1440 \var{errno}, in modo da poterlo ripristinare prima del ritorno del gestore
1441 (\texttt{\small 16--17}). In questo modo si preserva il valore della variabile
1442 visto dal corso di esecuzione principale del processo, che altrimenti sarebbe
1443 sovrascritto dal valore restituito nella successiva chiamata di \func{waitpid}.
1444
1445 Il compito principale del gestore è quello di ricevere lo stato di
1446 terminazione del processo, cosa che viene eseguita nel ciclo in
1447 (\texttt{\small 9--15}).  Il ciclo è necessario a causa di una caratteristica
1448 fondamentale della gestione dei segnali: abbiamo già accennato come fra la
1449 generazione di un segnale e l'esecuzione del gestore possa passare un certo
1450 lasso di tempo e niente ci assicura che il gestore venga eseguito prima della
1451 generazione di ulteriori segnali dello stesso tipo. In questo caso normalmente
1452 i segnali successivi vengono ``\textsl{fusi}'' col primo ed al processo ne
1453 viene recapitato soltanto uno.
1454
1455 Questo può essere un caso comune proprio con \const{SIGCHLD}, qualora capiti
1456 che molti processi figli terminino in rapida successione. Esso inoltre si
1457 presenta tutte le volte che un segnale viene bloccato: per quanti siano i
1458 segnali emessi durante il periodo di blocco, una volta che quest'ultimo sarà
1459 rimosso verrà recapitato un solo segnale.
1460
1461 Allora, nel caso della terminazione dei processi figli, se si chiamasse
1462 \func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un
1463 solo processo, anche se i processi terminati sono più di uno, e gli altri
1464 resterebbero in stato di \index{zombie} zombie per un tempo indefinito.
1465
1466 Per questo occorre ripetere la chiamata di \func{waitpid} fino a che essa non
1467 ritorni un valore nullo, segno che non resta nessun processo di cui si debba
1468 ancora ricevere lo stato di terminazione (si veda sez.~\ref{sec:proc_wait} per
1469 la sintassi della funzione). Si noti anche come la funzione venga invocata con
1470 il parametro \const{WNOHANG} che permette di evitare il suo blocco quando
1471 tutti gli stati di terminazione sono stati ricevuti.
1472
1473
1474
1475 \section{Gestione avanzata}
1476 \label{sec:sig_control}
1477
1478 Le funzioni esaminate finora fanno riferimento alle modalità più elementari
1479 della gestione dei segnali; non si sono pertanto ancora prese in
1480 considerazione le tematiche più complesse, collegate alle varie
1481 \itindex{race~condition} \textit{race condition} che i segnali possono
1482 generare e alla natura asincrona degli stessi.
1483
1484 Affronteremo queste problematiche in questa sezione, partendo da un esempio
1485 che le evidenzi, per poi prendere in esame le varie funzioni che permettono di
1486 risolvere i problemi più complessi connessi alla programmazione con i segnali,
1487 fino a trattare le caratteristiche generali della gestione dei medesimi nella
1488 casistica ordinaria.
1489
1490
1491 \subsection{Alcune problematiche aperte}
1492 \label{sec:sig_example}
1493
1494 Come accennato in sez.~\ref{sec:sig_pause_sleep} è possibile implementare
1495 \func{sleep} a partire dall'uso di \func{pause} e \func{alarm}. A prima vista
1496 questo può sembrare di implementazione immediata; ad esempio una semplice
1497 versione di \func{sleep} potrebbe essere quella illustrata in
1498 fig.~\ref{fig:sig_sleep_wrong}.
1499
1500 Dato che è nostra intenzione utilizzare \const{SIGALRM} il primo passo della
1501 nostra implementazione sarà quello di installare il relativo gestore salvando
1502 il precedente (\texttt{\small 14-17}).  Si effettuerà poi una chiamata ad
1503 \func{alarm} per specificare il tempo d'attesa per l'invio del segnale a cui
1504 segue la chiamata a \func{pause} per fermare il programma (\texttt{\small
1505   18-20}) fino alla sua ricezione.  Al ritorno di \func{pause}, causato dal
1506 ritorno del gestore (\texttt{\small 1-9}), si ripristina il gestore originario
1507 (\texttt{\small 21-22}) restituendo l'eventuale tempo rimanente
1508 (\texttt{\small 23-24}) che potrà essere diverso da zero qualora
1509 l'interruzione di \func{pause} venisse causata da un altro segnale.
1510
1511 \begin{figure}[!htb]
1512   \footnotesize \centering
1513   \begin{minipage}[c]{15cm}
1514     \includecodesample{listati/sleep_danger.c}
1515   \end{minipage}
1516   \normalsize 
1517   \caption{Una implementazione pericolosa di \func{sleep}.} 
1518   \label{fig:sig_sleep_wrong}
1519 \end{figure}
1520
1521 Questo codice però, a parte il non gestire il caso in cui si è avuta una
1522 precedente chiamata a \func{alarm} (che si è tralasciato per brevità),
1523 presenta una pericolosa \itindex{race~condition} \textit{race condition}.
1524 Infatti, se il processo viene interrotto fra la chiamata di \func{alarm} e
1525 \func{pause}, può capitare (ad esempio se il sistema è molto carico) che il
1526 tempo di attesa scada prima dell'esecuzione di quest'ultima, cosicché essa
1527 sarebbe eseguita dopo l'arrivo di \const{SIGALRM}. In questo caso ci si
1528 troverebbe di fronte ad un \itindex{deadlock} deadlock, in quanto \func{pause}
1529 non verrebbe mai più interrotta (se non in caso di un altro segnale).
1530
1531 Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
1532 SVr2) usando la funzione \func{longjmp} (vedi sez.~\ref{sec:proc_longjmp}) per
1533 uscire dal gestore; in questo modo, con una condizione sullo stato di
1534 uscita di quest'ultima, si può evitare la chiamata a \func{pause}, usando un
1535 codice del tipo di quello riportato in fig.~\ref{fig:sig_sleep_incomplete}.
1536
1537 \begin{figure}[!htb]
1538   \footnotesize \centering
1539   \begin{minipage}[c]{15cm}
1540     \includecodesample{listati/sleep_defect.c}
1541   \end{minipage}
1542   \normalsize 
1543   \caption{Una implementazione ancora malfunzionante di \func{sleep}.} 
1544   \label{fig:sig_sleep_incomplete}
1545 \end{figure}
1546
1547 In questo caso il gestore (\texttt{\small 18-27}) non ritorna come in
1548 fig.~\ref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 25}) per
1549 rientrare nel corpo principale del programma; dato che in questo caso il
1550 valore di uscita di \func{setjmp} è 1, grazie alla condizione in
1551 (\texttt{\small 9-12}) si evita comunque che \func{pause} sia chiamata a
1552 vuoto.
1553
1554 Ma anche questa implementazione comporta dei problemi; in questo caso infatti
1555 non viene gestita correttamente l'interazione con gli altri segnali; se
1556 infatti il segnale di allarme interrompe un altro gestore, l'esecuzione non
1557 riprenderà nel gestore in questione, ma nel ciclo principale, interrompendone
1558 inopportunamente l'esecuzione.  Lo stesso tipo di problemi si presenterebbero
1559 se si volesse usare \func{alarm} per stabilire un timeout su una qualunque
1560 system call bloccante.
1561
1562 Un secondo esempio è quello in cui si usa il segnale per notificare una
1563 qualche forma di evento; in genere quello che si fa in questo caso è impostare
1564 nel gestore un opportuno flag da controllare nel corpo principale del
1565 programma (con un codice del tipo di quello riportato in
1566 fig.~\ref{fig:sig_event_wrong}). La logica è quella di far impostare al
1567 gestore (\texttt{\small 14-19}) una variabile globale preventivamente
1568 inizializzata nel programma principale, il quale potrà determinare,
1569 osservandone il contenuto, l'occorrenza o meno del segnale, e prendere le
1570 relative azioni conseguenti (\texttt{\small 6-11}).
1571
1572 \begin{figure}[!htb]
1573   \footnotesize\centering
1574   \begin{minipage}[c]{15cm}
1575     \includecodesample{listati/sig_alarm.c}
1576   \end{minipage}
1577   \normalsize 
1578   \caption{Un esempio non funzionante del codice per il controllo di un
1579     evento generato da un segnale.}
1580   \label{fig:sig_event_wrong}
1581 \end{figure}
1582
1583 Questo è il tipico esempio di caso, già citato in
1584 sez.~\ref{sec:proc_race_cond}, in cui si genera una \itindex{race~condition}
1585 \textit{race condition}; infatti, in una situazione in cui un segnale è già
1586 arrivato (e \var{flag} è già ad 1) se un altro segnale segnale arriva
1587 immediatamente dopo l'esecuzione del controllo (\texttt{\small 6}) ma prima
1588 della cancellazione del flag (\texttt{\small 7}), la sua occorrenza sarà
1589 perduta.
1590
1591 Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono
1592 delle funzioni più sofisticate di quelle finora illustrate, queste hanno la
1593 loro origine nella semplice interfaccia dei primi sistemi Unix, ma con esse
1594 non è possibile gestire in maniera adeguata di tutti i possibili aspetti con
1595 cui un processo deve reagire alla ricezione di un segnale.
1596
1597
1598
1599 \subsection{Gli \textsl{insiemi di segnali} o \textit{signal set}}
1600 \label{sec:sig_sigset}
1601
1602 \itindbeg{signal~set} 
1603
1604 Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali
1605 originarie, nate con la semantica inaffidabile, hanno dei limiti non
1606 superabili; in particolare non è prevista nessuna funzione che permetta di
1607 gestire il blocco dei segnali o di verificare lo stato dei segnali pendenti.
1608 Per questo motivo lo standard POSIX.1, insieme alla nuova semantica dei
1609 segnali ha introdotto una interfaccia di gestione completamente nuova, che
1610 permette di ottenere un controllo molto più dettagliato. In particolare lo
1611 standard ha introdotto un nuovo tipo di dato \type{sigset\_t}, che permette di
1612 rappresentare un \textsl{insieme di segnali} (un \textit{signal set}, come
1613 viene usualmente chiamato), tale tipo di dato viene usato per gestire il
1614 blocco dei segnali.
1615
1616 In genere un \textsl{insieme di segnali} è rappresentato da un intero di
1617 dimensione opportuna, di solito pari al numero di bit dell'architettura della
1618 macchina,\footnote{nel caso dei PC questo comporta un massimo di 32 segnali
1619   distinti: dato che in Linux questi sono sufficienti non c'è necessità di
1620   nessuna struttura più complicata.} ciascun bit del quale è associato ad uno
1621 specifico segnale; in questo modo è di solito possibile implementare le
1622 operazioni direttamente con istruzioni elementari del processore. Lo standard
1623 POSIX.1 definisce cinque funzioni per la manipolazione degli insiemi di
1624 segnali: \funcd{sigemptyset}, \funcd{sigfillset}, \funcd{sigaddset},
1625 \funcd{sigdelset} e \funcd{sigismember}, i cui prototipi sono:
1626 \begin{functions}
1627   \headdecl{signal.h} 
1628   
1629   \funcdecl{int sigemptyset(sigset\_t *set)} Inizializza un insieme di segnali
1630   vuoto (in cui non c'è nessun segnale).
1631  
1632   \funcdecl{int sigfillset(sigset\_t *set)} Inizializza un insieme di segnali
1633   pieno (in cui ci sono tutti i segnali).
1634   
1635   \funcdecl{int sigaddset(sigset\_t *set, int signum)} Aggiunge il segnale
1636   \param{signum} all'insieme di segnali \param{set}.
1637
1638   \funcdecl{int sigdelset(sigset\_t *set, int signum)} Toglie il segnale
1639   \param{signum} dall'insieme di segnali \param{set}.
1640   
1641   \funcdecl{int sigismember(const sigset\_t *set, int signum)} Controlla se il
1642   segnale \param{signum} è nell'insieme di segnali \param{set}.
1643   
1644   \bodydesc{Le prime quattro funzioni ritornano 0 in caso di successo, mentre
1645     \func{sigismember} ritorna 1 se \param{signum} è in \param{set} e 0
1646     altrimenti. In caso di errore tutte ritornano $-1$, con \var{errno}
1647     impostata a \errval{EINVAL} (il solo errore possibile è che \param{signum}
1648     non sia un segnale valido).}
1649 \end{functions}
1650
1651 Dato che in generale non si può fare conto sulle caratteristiche di una
1652 implementazione (non è detto che si disponga di un numero di bit sufficienti
1653 per mettere tutti i segnali in un intero, o in \type{sigset\_t} possono essere
1654 immagazzinate ulteriori informazioni) tutte le operazioni devono essere
1655 comunque eseguite attraverso queste funzioni.
1656
1657 In genere si usa un insieme di segnali per specificare quali segnali si vuole
1658 bloccare, o per riottenere dalle varie funzioni di gestione la maschera dei
1659 segnali attivi (vedi sez.~\ref{sec:sig_sigmask}). Essi possono essere definiti
1660 in due diverse maniere, aggiungendo i segnali voluti ad un insieme vuoto
1661 ottenuto con \func{sigemptyset} o togliendo quelli che non servono da un
1662 insieme completo ottenuto con \func{sigfillset}. Infine \func{sigismember}
1663 permette di verificare la presenza di uno specifico segnale in un
1664 insieme.
1665
1666 \itindend{signal~set} 
1667
1668
1669 \subsection{La funzione \func{sigaction}}
1670 \label{sec:sig_sigaction}
1671
1672 Abbiamo già accennato in sez.~\ref{sec:sig_signal} i problemi di compatibilità
1673 relativi all'uso di \func{signal}. Per ovviare a tutto questo lo standard
1674 POSIX.1 ha ridefinito completamente l'interfaccia per la gestione dei segnali,
1675 rendendola molto più flessibile e robusta, anche se leggermente più complessa.
1676
1677 La funzione principale dell'interfaccia POSIX.1 per i segnali è
1678 \funcd{sigaction}. Essa ha sostanzialmente lo stesso uso di \func{signal},
1679 permette cioè di specificare le modalità con cui un segnale può essere gestito
1680 da un processo. Il suo prototipo è:
1681 \begin{prototype}{signal.h}{int sigaction(int signum, const struct sigaction
1682     *act, struct sigaction *oldact)} 
1683   
1684   Installa una nuova azione per il segnale \param{signum}.
1685   
1686   \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
1687     errore, nel qual caso \var{errno} assumerà i valori:
1688   \begin{errlist}
1689   \item[\errcode{EINVAL}] Si è specificato un numero di segnale invalido o si è
1690     cercato di installare il gestore per \const{SIGKILL} o
1691     \const{SIGSTOP}.
1692   \item[\errcode{EFAULT}] Si sono specificati indirizzi non validi.
1693   \end{errlist}}
1694 \end{prototype}
1695
1696 La funzione serve ad installare una nuova \textsl{azione} per il segnale
1697 \param{signum}; si parla di \textsl{azione} e non di \textsl{gestore}
1698 come nel caso di \func{signal}, in quanto la funzione consente di specificare
1699 le varie caratteristiche della risposta al segnale, non solo la funzione che
1700 verrà eseguita alla sua occorrenza.  Per questo lo standard raccomanda di
1701 usare sempre questa funzione al posto di \func{signal} (che in genere viene
1702 definita tramite essa), in quanto permette un controllo completo su tutti gli
1703 aspetti della gestione di un segnale, sia pure al prezzo di una maggiore
1704 complessità d'uso.
1705
1706 Se il puntatore \param{act} non è nullo, la funzione installa la nuova azione
1707 da esso specificata, se \param{oldact} non è nullo il valore dell'azione
1708 corrente viene restituito indietro.  Questo permette (specificando \param{act}
1709 nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
1710 che non consente di ottenere l'azione corrente senza installarne una nuova.
1711
1712 Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
1713 tramite la quale si specificano tutte le caratteristiche dell'azione associata
1714 ad un segnale.  Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
1715 definita secondo quanto riportato in fig.~\ref{fig:sig_sigaction}. Il campo
1716 \var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
1717 più usato.
1718
1719 \begin{figure}[!htb]
1720   \footnotesize \centering
1721   \begin{minipage}[c]{15cm}
1722     \includestruct{listati/sigaction.h}
1723   \end{minipage} 
1724   \normalsize 
1725   \caption{La struttura \structd{sigaction}.} 
1726   \label{fig:sig_sigaction}
1727 \end{figure}
1728
1729 Il campo \var{sa\_mask} serve ad indicare l'insieme dei segnali che devono
1730 essere bloccati durante l'esecuzione del gestore, ad essi viene comunque
1731 sempre aggiunto il segnale che ne ha causato la chiamata, a meno che non si
1732 sia specificato con \var{sa\_flag} un comportamento diverso. Quando il
1733 gestore ritorna comunque la maschera dei segnali bloccati (vedi
1734 sez.~\ref{sec:sig_sigmask}) viene ripristinata al valore precedente
1735 l'invocazione.
1736
1737 L'uso di questo campo permette ad esempio di risolvere il problema residuo
1738 dell'implementazione di \code{sleep} mostrata in
1739 fig.~\ref{fig:sig_sleep_incomplete}. In quel caso infatti se il segnale di
1740 allarme avesse interrotto un altro gestore questo non sarebbe stato eseguito
1741 correttamente; la cosa poteva essere prevenuta installando gli altri gestori
1742 usando \var{sa\_mask} per bloccare \const{SIGALRM} durante la loro esecuzione.
1743 Il valore di \var{sa\_flag} permette di specificare vari aspetti del
1744 comportamento di \func{sigaction}, e della reazione del processo ai vari
1745 segnali; i valori possibili ed il relativo significato sono riportati in
1746 tab.~\ref{tab:sig_sa_flag}.
1747
1748 \begin{table}[htb]
1749   \footnotesize
1750   \centering
1751   \begin{tabular}[c]{|l|p{8cm}|}
1752     \hline
1753     \textbf{Valore} & \textbf{Significato} \\
1754     \hline
1755     \hline
1756     \const{SA\_NOCLDSTOP}& Se il segnale è \const{SIGCHLD} allora non deve
1757                            essere notificato quando il processo figlio viene
1758                            fermato da uno dei segnali \const{SIGSTOP},
1759                            \const{SIGTSTP}, \const{SIGTTIN} o 
1760                            \const{SIGTTOU}.\\
1761     \const{SA\_RESETHAND}& Ristabilisce l'azione per il segnale al valore 
1762                            predefinito una volta che il gestore è stato
1763                            lanciato, riproduce cioè il comportamento della
1764                            semantica inaffidabile.\\  
1765     \const{SA\_ONESHOT}  & Nome obsoleto, sinonimo non standard di
1766                            \const{SA\_RESETHAND}; da evitare. \\ 
1767     \const{SA\_ONSTACK}  & Stabilisce l'uso di uno \itindex{stack} stack 
1768                            alternativo per l'esecuzione del gestore (vedi
1769                            sez.~\ref{sec:sig_specific_features}).\\ 
1770     \const{SA\_RESTART}  & Riavvia automaticamente le \textit{slow system
1771                            call} quando vengono interrotte dal suddetto
1772                            segnale; riproduce cioè il comportamento standard
1773                            di BSD.\index{system~call~lente}\\ 
1774     \const{SA\_NODEFER}  & Evita che il segnale corrente sia bloccato durante
1775                            l'esecuzione del gestore.\\
1776     \const{SA\_NOMASK}   & Nome obsoleto, sinonimo non standard di
1777                            \const{SA\_NODEFER}.\\ 
1778     \const{SA\_SIGINFO}  & Deve essere specificato quando si vuole usare un
1779                            gestore in forma estesa usando
1780                            \var{sa\_sigaction} al posto di
1781                            \var{sa\_handler}.\\
1782     \const{SA\_NOCLDWAIT}& Se il segnale è \const{SIGCHLD} allora o processi
1783                            figli non divenire \textit{zombie} quando
1784                            terminano.\footnotemark \\ 
1785     \hline
1786   \end{tabular}
1787   \caption{Valori del campo \var{sa\_flag} della struttura \struct{sigaction}.}
1788   \label{tab:sig_sa_flag}
1789 \end{table}
1790
1791 \footnotetext{questa funzionalità è stata introdotta nel kernel 2.6 e va a
1792   modificare il comportamento di \func{waitpid}.}
1793
1794 % TODO con il 2.6 sono stati aggiunti SA_NOCLDWAIT e altro, documentare
1795
1796 Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette
1797 di utilizzare due forme diverse di gestore,\footnote{La possibilità è prevista
1798   dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x
1799   con l'introduzione dei segnali real-time (vedi
1800   sez.~\ref{sec:sig_real_time}); in precedenza era possibile ottenere alcune
1801   informazioni addizionali usando \var{sa\_handler} con un secondo parametro
1802   addizionale di tipo \var{sigcontext}, che adesso è deprecato.}  da
1803 specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO},
1804 rispettivamente attraverso i campi \var{sa\_sigaction} o
1805 \var{sa\_handler},\footnote{i due tipi devono essere usati in maniera
1806   alternativa, in certe implementazioni questi campi vengono addirittura
1807   definiti come \ctyp{union}.}  Quest'ultima è quella classica usata anche con
1808 \func{signal}, mentre la prima permette di usare un gestore più complesso, in
1809 grado di ricevere informazioni più dettagliate dal sistema, attraverso la
1810 struttura \struct{siginfo\_t}, riportata in fig.~\ref{fig:sig_siginfo_t}.
1811
1812 \begin{figure}[!htb]
1813   \footnotesize \centering
1814   \begin{minipage}[c]{15cm}
1815     \includestruct{listati/siginfo_t.h}
1816   \end{minipage} 
1817   \normalsize 
1818   \caption{La struttura \structd{siginfo\_t}.} 
1819   \label{fig:sig_siginfo_t}
1820 \end{figure}
1821  
1822 Installando un gestore di tipo \var{sa\_sigaction} diventa allora possibile
1823 accedere alle informazioni restituite attraverso il puntatore a questa
1824 struttura. Tutti i segnali impostano i campi \var{si\_signo}, che riporta il
1825 numero del segnale ricevuto, \var{si\_errno}, che riporta, quando diverso da
1826 zero, il codice dell'errore associato al segnale, e \var{si\_code}, che viene
1827 usato dal kernel per specificare maggiori dettagli riguardo l'evento che ha
1828 causato l'emissione del segnale.
1829
1830 In generale \var{si\_code} contiene, per i segnali generici, per quelli
1831 real-time e per tutti quelli inviati tramite \func{kill}, informazioni circa
1832 l'origine del segnale (se generato dal kernel, da un timer, da \func{kill},
1833 ecc.). Alcuni segnali però usano \var{si\_code} per fornire una informazione
1834 specifica: ad esempio i vari segnali di errore (\const{SIGFPE},
1835 \const{SIGILL}, \const{SIGBUS} e \const{SIGSEGV}) lo usano per fornire
1836 maggiori dettagli riguardo l'errore (come il tipo di errore aritmetico, di
1837 istruzione illecita o di violazione di memoria) mentre alcuni segnali di
1838 controllo (\const{SIGCHLD}, \const{SIGTRAP} e \const{SIGPOLL}) forniscono
1839 altre informazioni specifiche.  In tutti i casi il valore del campo è
1840 riportato attraverso delle costanti (le cui definizioni si trovano
1841 \file{bits/siginfo.h}) il cui elenco dettagliato è disponibile nella pagina di
1842 manuale di \func{sigaction}.
1843
1844 Il resto della struttura è definito come \ctyp{union} ed i valori
1845 eventualmente presenti dipendono dal segnale, così \const{SIGCHLD} ed i
1846 segnali real-time (vedi sez.~\ref{sec:sig_real_time}) inviati tramite
1847 \func{kill} avvalorano \var{si\_pid} e \var{si\_uid} coi valori corrispondenti
1848 al processo che ha emesso il segnale, \const{SIGILL}, \const{SIGFPE},
1849 \const{SIGSEGV} e \const{SIGBUS} avvalorano \var{si\_addr} con l'indirizzo in
1850 cui è avvenuto l'errore, \const{SIGIO} (vedi
1851 sez.~\ref{sec:file_asyncronous_io}) avvalora \var{si\_fd} con il numero del
1852 file descriptor e \var{si\_band} per i \itindex{out-of-band} dati urgenti (vedi
1853 sez.~\ref{sec:TCP_urgent_data}) su un socket.
1854
1855 Benché sia possibile usare nello stesso programma sia \func{sigaction} che
1856 \func{signal} occorre molta attenzione, in quanto le due funzioni possono
1857 interagire in maniera anomala. Infatti l'azione specificata con
1858 \struct{sigaction} contiene un maggior numero di informazioni rispetto al
1859 semplice indirizzo del gestore restituito da \func{signal}.  Per questo motivo
1860 se si usa quest'ultima per installare un gestore sostituendone uno
1861 precedentemente installato con \func{sigaction}, non sarà possibile effettuare
1862 un ripristino corretto dello stesso.
1863
1864 Per questo è sempre opportuno usare \func{sigaction}, che è in grado di
1865 ripristinare correttamente un gestore precedente, anche se questo è stato
1866 installato con \func{signal}. In generale poi non è il caso di usare il valore
1867 di ritorno di \func{signal} come campo \var{sa\_handler}, o viceversa, dato
1868 che in certi sistemi questi possono essere diversi. In definitiva dunque, a
1869 meno che non si sia vincolati all'aderenza stretta allo standard ISO C, è
1870 sempre il caso di evitare l'uso di \func{signal} a favore di \func{sigaction}.
1871
1872 \begin{figure}[!htb]
1873   \footnotesize  \centering
1874   \begin{minipage}[c]{15.6cm}
1875     \includecodesample{listati/Signal.c}
1876   \end{minipage} 
1877   \normalsize 
1878   \caption{La funzione \func{Signal}, equivalente a \func{signal}, definita
1879     attraverso \func{sigaction}.}
1880   \label{fig:sig_Signal_code}
1881 \end{figure}
1882
1883 Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
1884 che abbia le stesse caratteristiche di \func{signal}, a definire attraverso
1885 \func{sigaction} una funzione equivalente, il cui codice è riportato in
1886 fig.~\ref{fig:sig_Signal_code} (il codice completo si trova nel file
1887 \file{SigHand.c} nei sorgenti allegati).  Si noti come, essendo la funzione
1888 estremamente semplice, è definita come \direct{inline}.\footnote{la direttiva
1889   \direct{inline} viene usata per dire al compilatore di trattare la funzione
1890   cui essa fa riferimento in maniera speciale inserendo il codice direttamente
1891   nel testo del programma.  Anche se i compilatori più moderni sono in grado
1892   di effettuare da soli queste manipolazioni (impostando le opportune
1893   ottimizzazioni) questa è una tecnica usata per migliorare le prestazioni per
1894   le funzioni piccole ed usate di frequente (in particolare nel kernel, dove
1895   in certi casi le ottimizzazioni dal compilatore, tarate per l'uso in user
1896   space, non sono sempre adatte). In tal caso infatti le istruzioni per creare
1897   un nuovo frame nello \itindex{stack} stack per chiamare la funzione
1898   costituirebbero una parte rilevante del codice, appesantendo inutilmente il
1899   programma.  Originariamente questo comportamento veniva ottenuto con delle
1900   macro, ma queste hanno tutta una serie di problemi di sintassi nel passaggio
1901   degli argomenti (si veda ad esempio \cite{PratC}) che in questo modo possono
1902   essere evitati.}
1903
1904
1905
1906 \subsection{La gestione della \textsl{maschera dei segnali} o 
1907   \textit{signal mask}}
1908 \label{sec:sig_sigmask}
1909
1910 \itindbeg{signal~mask}
1911 Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like
1912 permettono di bloccare temporaneamente (o di eliminare completamente,
1913 impostando \const{SIG\_IGN} come azione) la consegna dei segnali ad un
1914 processo. Questo è fatto specificando la cosiddetta \textsl{maschera dei
1915   segnali} (o \textit{signal mask}) del processo\footnote{nel caso di Linux
1916   essa è mantenuta dal campo \var{blocked} della \struct{task\_struct} del
1917   processo.} cioè l'insieme dei segnali la cui consegna è bloccata. Abbiamo
1918 accennato in sez.~\ref{sec:proc_fork} che la \textit{signal mask} viene
1919 ereditata dal padre alla creazione di un processo figlio, e abbiamo visto al
1920 paragrafo precedente che essa può essere modificata, durante l'esecuzione di
1921 un gestore, attraverso l'uso dal campo \var{sa\_mask} di \struct{sigaction}.
1922
1923 Uno dei problemi evidenziatisi con l'esempio di fig.~\ref{fig:sig_event_wrong}
1924 è che in molti casi è necessario proteggere delle sezioni di codice (nel caso
1925 in questione la sezione fra il controllo e la eventuale cancellazione del flag
1926 che testimoniava l'avvenuta occorrenza del segnale) in modo da essere sicuri
1927 che essi siano eseguite senza interruzioni.
1928
1929 Le operazioni più semplici, come l'assegnazione o il controllo di una
1930 variabile (per essere sicuri si può usare il tipo \type{sig\_atomic\_t}) di
1931 norma sono atomiche; quando si devono eseguire operazioni più complesse si può
1932 invece usare la funzione \funcd{sigprocmask} che permette di bloccare uno o
1933 più segnali; il suo prototipo è:
1934 \begin{prototype}{signal.h}
1935 {int sigprocmask(int how, const sigset\_t *set, sigset\_t *oldset)} 
1936   
1937   Cambia la \textsl{maschera dei segnali} del processo corrente.
1938   
1939   \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
1940     errore, nel qual caso \var{errno} assumerà i valori:
1941   \begin{errlist}
1942   \item[\errcode{EINVAL}] Si è specificato un numero di segnale invalido.
1943   \item[\errcode{EFAULT}] Si sono specificati indirizzi non validi.
1944   \end{errlist}}
1945 \end{prototype}
1946
1947 La funzione usa l'insieme di segnali dato all'indirizzo \param{set} per
1948 modificare la maschera dei segnali del processo corrente. La modifica viene
1949 effettuata a seconda del valore dell'argomento \param{how}, secondo le modalità
1950 specificate in tab.~\ref{tab:sig_procmask_how}. Qualora si specifichi un valore
1951 non nullo per \param{oldset} la maschera dei segnali corrente viene salvata a
1952 quell'indirizzo.
1953
1954 \begin{table}[htb]
1955   \footnotesize
1956   \centering
1957   \begin{tabular}[c]{|l|p{8cm}|}
1958     \hline
1959     \textbf{Valore} & \textbf{Significato} \\
1960     \hline
1961     \hline
1962     \const{SIG\_BLOCK}   & L'insieme dei segnali bloccati è l'unione fra
1963                            quello specificato e quello corrente.\\
1964     \const{SIG\_UNBLOCK} & I segnali specificati in \param{set} sono rimossi
1965                            dalla maschera dei segnali, specificare la
1966                            cancellazione di un segnale non bloccato è legale.\\
1967     \const{SIG\_SETMASK} & La maschera dei segnali è impostata al valore
1968                            specificato da \param{set}.\\
1969     \hline
1970   \end{tabular}
1971   \caption{Valori e significato dell'argomento \param{how} della funzione
1972     \func{sigprocmask}.}
1973   \label{tab:sig_procmask_how}
1974 \end{table}
1975
1976 In questo modo diventa possibile proteggere delle sezioni di codice bloccando
1977 l'insieme di segnali voluto per poi riabilitarli alla fine della
1978 \index{sezione~critica} sezione critica. La funzione permette di risolvere
1979 problemi come quelli mostrati in fig.~\ref{fig:sig_event_wrong}, proteggendo
1980 la sezione fra il controllo del flag e la sua cancellazione.
1981
1982 La funzione può essere usata anche all'interno di un gestore, ad esempio
1983 per riabilitare la consegna del segnale che l'ha invocato, in questo caso però
1984 occorre ricordare che qualunque modifica alla maschera dei segnali viene
1985 perduta alla conclusione del terminatore. 
1986
1987 Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
1988 dei casi di \itindex{race~condition} \textit{race condition} restano aperte
1989 alcune possibilità legate all'uso di \func{pause}; il caso è simile a quello
1990 del problema illustrato nell'esempio di fig.~\ref{fig:sig_sleep_incomplete}, e
1991 cioè la possibilità che il processo riceva il segnale che si intende usare per
1992 uscire dallo stato di attesa invocato con \func{pause} immediatamente prima
1993 dell'esecuzione di quest'ultima. Per poter effettuare atomicamente la modifica
1994 della maschera dei segnali (di solito attivandone uno specifico) insieme alla
1995 sospensione del processo lo standard POSIX ha previsto la funzione
1996 \funcd{sigsuspend}, il cui prototipo è:
1997 \begin{prototype}{signal.h}
1998 {int sigsuspend(const sigset\_t *mask)} 
1999   
2000   Imposta la \textit{signal mask} specificata, mettendo in attesa il processo.
2001   
2002   \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
2003     errore, nel qual caso \var{errno} assumerà i valori:
2004   \begin{errlist}
2005   \item[\errcode{EINVAL}] Si è specificato un numero di segnale invalido.
2006   \item[\errcode{EFAULT}] Si sono specificati indirizzi non validi.
2007   \end{errlist}}
2008 \end{prototype}
2009
2010 Come esempio dell'uso di queste funzioni proviamo a riscrivere un'altra volta
2011 l'esempio di implementazione di \code{sleep}. Abbiamo accennato in
2012 sez.~\ref{sec:sig_sigaction} come con \func{sigaction} sia possibile bloccare
2013 \const{SIGALRM} nell'installazione dei gestori degli altri segnali, per poter
2014 usare l'implementazione vista in fig.~\ref{fig:sig_sleep_incomplete} senza
2015 interferenze.  Questo però comporta una precauzione ulteriore al semplice uso
2016 della funzione, vediamo allora come usando la nuova interfaccia è possibile
2017 ottenere un'implementazione, riportata in fig.~\ref{fig:sig_sleep_ok} che non
2018 presenta neanche questa necessità.
2019
2020 \begin{figure}[!htb]
2021   \footnotesize   \centering
2022   \begin{minipage}[c]{15.6cm}
2023     \includecodesample{listati/sleep.c}
2024   \end{minipage} 
2025   \normalsize 
2026   \caption{Una implementazione completa di \func{sleep}.} 
2027   \label{fig:sig_sleep_ok}
2028 \end{figure}
2029
2030 Per evitare i problemi di interferenza con gli altri segnali in questo caso
2031 non si è usato l'approccio di fig.~\ref{fig:sig_sleep_incomplete} evitando
2032 l'uso di \func{longjmp}. Come in precedenza il gestore (\texttt{\small 27-30})
2033 non esegue nessuna operazione, limitandosi a ritornare per interrompere il
2034 programma messo in attesa.
2035
2036 La prima parte della funzione (\texttt{\small 6-10}) provvede ad installare
2037 l'opportuno gestore per \const{SIGALRM}, salvando quello originario, che
2038 sarà ripristinato alla conclusione della stessa (\texttt{\small 23}); il passo
2039 successivo è quello di bloccare \const{SIGALRM} (\texttt{\small 11-14}) per
2040 evitare che esso possa essere ricevuto dal processo fra l'esecuzione di
2041 \func{alarm} (\texttt{\small 16}) e la sospensione dello stesso. Nel fare
2042 questo si salva la maschera corrente dei segnali, che sarà ripristinata alla
2043 fine (\texttt{\small 22}), e al contempo si prepara la maschera dei segnali
2044 \var{sleep\_mask} per riattivare \const{SIGALRM} all'esecuzione di
2045 \func{sigsuspend}.  
2046
2047 In questo modo non sono più possibili \itindex{race~condition} \textit{race
2048   condition} dato che \const{SIGALRM} viene disabilitato con
2049 \func{sigprocmask} fino alla chiamata di \func{sigsuspend}.  Questo metodo è
2050 assolutamente generale e può essere applicato a qualunque altra situazione in
2051 cui si deve attendere per un segnale, i passi sono sempre i seguenti:
2052 \begin{enumerate*}
2053 \item Leggere la maschera dei segnali corrente e bloccare il segnale voluto
2054   con \func{sigprocmask};
2055 \item Mandare il processo in attesa con \func{sigsuspend} abilitando la
2056   ricezione del segnale voluto;
2057 \item Ripristinare la maschera dei segnali originaria.
2058 \end{enumerate*}
2059 Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi
2060 riabilitarla immediatamente dopo, in questo modo si evita il
2061 \itindex{deadlock} deadlock dovuto all'arrivo del segnale prima
2062 dell'esecuzione di \func{sigsuspend}.
2063
2064 \itindend{signal~mask}
2065
2066
2067 \subsection{Ulteriori funzioni di gestione}
2068 \label{sec:sig_specific_features}
2069
2070 In questo ultimo paragrafo esamineremo le rimanenti funzioni di gestione dei
2071 segnali non descritte finora, relative agli aspetti meno utilizzati e più
2072 ``\textsl{esoterici}'' della interfaccia.
2073
2074 La prima di queste funzioni è \funcd{sigpending}, anch'essa introdotta dallo
2075 standard POSIX.1; il suo prototipo è:
2076 \begin{prototype}{signal.h}
2077 {int sigpending(sigset\_t *set)} 
2078   
2079 Scrive in \param{set} l'insieme dei segnali pendenti.
2080   
2081   \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
2082     errore.}
2083 \end{prototype}
2084
2085 La funzione permette di ricavare quali sono i segnali pendenti per il processo
2086 in corso, cioè i segnali che sono stati inviati dal kernel ma non sono stati
2087 ancora ricevuti dal processo in quanto bloccati. Non esiste una funzione
2088 equivalente nella vecchia interfaccia, ma essa è tutto sommato poco utile,
2089 dato che essa può solo assicurare che un segnale è stato inviato, dato che
2090 escluderne l'avvenuto invio al momento della chiamata non significa nulla
2091 rispetto a quanto potrebbe essere in un qualunque momento successivo.
2092
2093 Una delle caratteristiche di BSD, disponibile anche in Linux, è la possibilità
2094 di usare uno \itindex{stack} stack alternativo per i segnali; è cioè possibile
2095 fare usare al sistema un altro \itindex{stack} stack (invece di quello
2096 relativo al processo, vedi sez.~\ref{sec:proc_mem_layout}) solo durante
2097 l'esecuzione di un gestore.  L'uso di uno stack alternativo è del tutto
2098 trasparente ai gestori, occorre però seguire una certa procedura:
2099 \begin{enumerate}
2100 \item Allocare un'area di memoria di dimensione sufficiente da usare come
2101   stack alternativo;
2102 \item Usare la funzione \func{sigaltstack} per rendere noto al sistema
2103   l'esistenza e la locazione dello stack alternativo;
2104 \item Quando si installa un gestore occorre usare \func{sigaction}
2105   specificando il flag \const{SA\_ONSTACK} (vedi tab.~\ref{tab:sig_sa_flag})
2106   per dire al sistema di usare lo stack alternativo durante l'esecuzione del
2107   gestore.
2108 \end{enumerate}
2109
2110 In genere il primo passo viene effettuato allocando un'opportuna area di
2111 memoria con \code{malloc}; in \file{signal.h} sono definite due costanti,
2112 \const{SIGSTKSZ} e \const{MINSIGSTKSZ}, che possono essere utilizzate per
2113 allocare una quantità di spazio opportuna, in modo da evitare overflow. La
2114 prima delle due è la dimensione canonica per uno \itindex{stack} stack di
2115 segnali e di norma è sufficiente per tutti gli usi normali.
2116
2117 La seconda è lo spazio che occorre al sistema per essere in grado di lanciare
2118 il gestore e la dimensione di uno stack alternativo deve essere sempre
2119 maggiore di questo valore. Quando si conosce esattamente quanto è lo spazio
2120 necessario al gestore gli si può aggiungere questo valore per allocare uno
2121 \itindex{stack} stack di dimensione sufficiente.
2122
2123 Come accennato, per poter essere usato, lo \itindex{stack} stack per i segnali
2124 deve essere indicato al sistema attraverso la funzione \funcd{sigaltstack}; il
2125 suo prototipo è:
2126 \begin{prototype}{signal.h}
2127 {int sigaltstack(const stack\_t *ss, stack\_t *oss)}
2128   
2129 Installa un nuovo stack per i segnali.
2130   
2131   \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
2132     errore, nel qual caso \var{errno} assumerà i valori:
2133
2134   \begin{errlist}
2135   \item[\errcode{ENOMEM}] La dimensione specificata per il nuovo stack è minore
2136   di \const{MINSIGSTKSZ}.
2137   \item[\errcode{EPERM}] Uno degli indirizzi non è valido.
2138   \item[\errcode{EFAULT}] Si è cercato di cambiare lo stack alternativo mentre
2139   questo è attivo (cioè il processo è in esecuzione su di esso).
2140   \item[\errcode{EINVAL}] \param{ss} non è nullo e \var{ss\_flags} contiene un
2141   valore diverso da zero che non è \const{SS\_DISABLE}.
2142   \end{errlist}}
2143 \end{prototype}
2144
2145 La funzione prende come argomenti puntatori ad una struttura di tipo
2146 \var{stack\_t}, definita in fig.~\ref{fig:sig_stack_t}. I due valori
2147 \param{ss} e \param{oss}, se non nulli, indicano rispettivamente il nuovo
2148 \itindex{stack} stack da installare e quello corrente (che viene restituito
2149 dalla funzione per un successivo ripristino).
2150
2151 \begin{figure}[!htb]
2152   \footnotesize \centering
2153   \begin{minipage}[c]{15cm}
2154     \includestruct{listati/stack_t.h}
2155   \end{minipage} 
2156   \normalsize 
2157   \caption{La struttura \structd{stack\_t}.} 
2158   \label{fig:sig_stack_t}
2159 \end{figure}
2160
2161 Il campo \var{ss\_sp} di \struct{stack\_t} indica l'indirizzo base dello
2162 \itindex{stack} stack, mentre \var{ss\_size} ne indica la dimensione; il campo
2163 \var{ss\_flags} invece indica lo stato dello stack. Nell'indicare un nuovo
2164 stack occorre inizializzare \var{ss\_sp} e \var{ss\_size} rispettivamente al
2165 puntatore e alla dimensione della memoria allocata, mentre \var{ss\_flags}
2166 deve essere nullo.  Se invece si vuole disabilitare uno stack occorre indicare
2167 \const{SS\_DISABLE} come valore di \var{ss\_flags} e gli altri valori saranno
2168 ignorati.
2169
2170 Se \param{oss} non è nullo verrà restituito dalla funzione indirizzo e
2171 dimensione dello \itindex{stack} stack corrente nei relativi campi, mentre
2172 \var{ss\_flags} potrà assumere il valore \const{SS\_ONSTACK} se il processo è
2173 in esecuzione sullo stack alternativo (nel qual caso non è possibile
2174 cambiarlo) e \const{SS\_DISABLE} se questo non è abilitato.
2175
2176 In genere si installa uno \itindex{stack} stack alternativo per i segnali
2177 quando si teme di avere problemi di esaurimento dello stack standard o di
2178 superamento di un limite (vedi sez.~\ref{sec:sys_resource_limit}) imposto con
2179 chiamate del tipo \code{setrlimit(RLIMIT\_STACK, \&rlim)}.  In tal caso
2180 infatti si avrebbe un segnale di \const{SIGSEGV}, che potrebbe essere gestito
2181 soltanto avendo abilitato uno \itindex{stack} stack alternativo.
2182
2183 Si tenga presente che le funzioni chiamate durante l'esecuzione sullo stack
2184 alternativo continueranno ad usare quest'ultimo, che, al contrario di quanto
2185 avviene per lo \itindex{stack} stack ordinario dei processi, non si accresce
2186 automaticamente (ed infatti eccederne le dimensioni può portare a conseguenze
2187 imprevedibili).  Si ricordi infine che una chiamata ad una funzione della
2188 famiglia \func{exec} cancella ogni stack alternativo.
2189
2190 Abbiamo visto in fig.~\ref{fig:sig_sleep_incomplete} come si possa usare
2191 \func{longjmp} per uscire da un gestore rientrando direttamente nel corpo
2192 del programma; sappiamo però che nell'esecuzione di un gestore il segnale
2193 che l'ha invocato viene bloccato, e abbiamo detto che possiamo ulteriormente
2194 modificarlo con \func{sigprocmask}. 
2195
2196 Resta quindi il problema di cosa succede alla maschera dei segnali quando si
2197 esce da un gestore usando questa funzione. Il comportamento dipende
2198 dall'implementazione; in particolare BSD prevede che sia ripristinata la
2199 maschera dei segnali precedente l'invocazione, come per un normale ritorno,
2200 mentre System V no.
2201
2202 Lo standard POSIX.1 non specifica questo comportamento per \func{setjmp} e
2203 \func{longjmp}, ed il comportamento delle \acr{glibc} dipende da quale delle
2204 caratteristiche si sono abilitate con le macro viste in
2205 sez.~\ref{sec:intro_gcc_glibc_std}.
2206
2207 Lo standard POSIX però prevede anche la presenza di altre due funzioni
2208 \funcd{sigsetjmp} e \funcd{siglongjmp}, che permettono di decidere quale dei
2209 due comportamenti il programma deve assumere; i loro prototipi sono:
2210 \begin{functions}
2211   \headdecl{setjmp.h} 
2212   
2213   \funcdecl{int sigsetjmp(sigjmp\_buf env, int savesigs)} Salva il contesto
2214   dello stack per un \index{salto~non-locale} salto non-locale.
2215  
2216   \funcdecl{void siglongjmp(sigjmp\_buf env, int val)} Esegue un salto
2217   non-locale su un precedente contesto.
2218
2219   \bodydesc{Le due funzioni sono identiche alle analoghe \func{setjmp} e
2220     \func{longjmp} di sez.~\ref{sec:proc_longjmp}, ma consentono di specificare
2221     il comportamento sul ripristino o meno della maschera dei segnali.}
2222 \end{functions}
2223
2224 Le due funzioni prendono come primo argomento la variabile su cui viene
2225 salvato il contesto dello \itindex{stack} stack per permettere il
2226 \index{salto~non-locale} salto non-locale; nel caso specifico essa è di tipo
2227 \type{sigjmp\_buf}, e non \type{jmp\_buf} come per le analoghe di
2228 sez.~\ref{sec:proc_longjmp} in quanto in questo caso viene salvata anche la
2229 maschera dei segnali.
2230
2231 Nel caso di \func{sigsetjmp}, se si specifica un valore di \param{savesigs}
2232 diverso da zero la maschera dei valori sarà salvata in \param{env} e
2233 ripristinata in un successivo \func{siglongjmp}; quest'ultima funzione, a
2234 parte l'uso di \type{sigjmp\_buf} per \param{env}, è assolutamente identica a
2235 \func{longjmp}.
2236
2237
2238 \subsection{Criteri di programmazione per i gestori dei segnali}
2239 \label{sec:sig_signal_handler}
2240
2241 Abbiamo finora parlato dei gestori dei segnali come funzioni chiamate in
2242 corrispondenza della consegna di un segnale. In realtà un gestore non può
2243 essere una funzione qualunque, in quanto esso può essere eseguito in
2244 corrispondenza all'interruzione in un punto qualunque del programma principale,
2245 ed ad esempio può essere problematico chiamare all'interno di un gestore di
2246 segnali la stessa funzione che dal segnale è stata interrotta.
2247
2248 \index{funzioni~sicure|(}
2249
2250 Il concetto è comunque più generale e porta ad una distinzione fra quelle che
2251 che POSIX chiama \textsl{funzioni insicure} (\textit{n'Usane function}) e
2252 \textsl{funzioni sicure} (\textit{safe function}); quando un segnale
2253 interrompe una funzione insicura ed il gestore chiama al suo interno una
2254 funzione insicura il sistema può dare luogo ad un comportamento indefinito.
2255
2256 Tutto questo significa che un gestore di segnale deve essere programmato con
2257 molta cura per evitare questa evenienza, pertanto è non è possibile chiamare
2258 al suo interno una funzione qualunque, e si può ricorrere soltanto all'uso di
2259 funzioni sicure.
2260
2261 L'elenco delle funzioni sicure varia a secondo dello standard a cui si fa
2262 riferimento, secondo quanto riportato dallo standard POSIX 1003.1 nella
2263 revisione del 2003, le ``\textit{signal safe function}'' che possono essere
2264 chiamate anche all'interno di un gestore di segnali sono quelle della lista
2265 riportata in fig.~\ref{fig:sig_safe_functions}.
2266
2267 \begin{figure}[!htb]
2268   \footnotesize \centering
2269   \begin{minipage}[c]{15cm}
2270     \func{\_exit}, \func{abort}, \func{accept}, \func{access},
2271     \func{aio\_error} \func{aio\_return}, \func{aio\_suspend}, \func{alarm},
2272     \func{bind}, \func{cfgetispeed}, \func{cfgetospeed}, \func{cfsetispeed},
2273     \func{cfsetospeed}, \func{chdir}, \func{chmod}, \func{chown},
2274     \func{clock\_gettime}, \func{close}, \func{connect}, \func{creat},
2275     \func{dup}, \func{dup2}, \func{execle}, \func{execve}, \func{fchmod},
2276     \func{fchown}, \func{fcntl}, \func{fdatasync}, \func{fork},
2277     \func{fpathconf}, \func{fstat}, \func{fsync}, \func{ftruncate},
2278     \func{getegid}, \func{geteuid}, \func{getgid}, \func{getgroups},
2279     \func{getpeername}, \func{getpgrp}, \func{getpid}, \func{getppid},
2280     \func{getsockname}, \func{getsockopt}, \func{getuid}, \func{kill},
2281     \func{link}, \func{listen}, \func{lseek}, \func{lstat}, \func{mkdir},
2282     \func{mkfifo}, \func{open}, \func{pathconf}, \func{pause}, \func{pipe},
2283     \func{poll}, \func{posix\_trace\_event}, \func{pselect}, \func{raise},
2284     \func{read}, \func{readlink}, \func{recv}, \func{recvfrom},
2285     \func{recvmsg}, \func{rename}, \func{rmdir}, \func{select},
2286     \func{sem\_post}, \func{send}, \func{sendmsg}, \func{sendto},
2287     \func{setgid}, \func{setpgid}, \func{setsid}, \func{setsockopt},
2288     \func{setuid}, \func{shutdown}, \func{sigaction}, \func{sigaddset},
2289     \func{sigdelset}, \func{sigemptyset}, \func{sigfillset},
2290     \func{sigismember}, \func{signal}, \func{sigpause}, \func{sigpending},
2291     \func{sigprocmask}, \func{sigqueue}, \func{sigset}, \func{sigsuspend},
2292     \func{sleep}, \func{socket}, \func{socketpair}, \func{stat},
2293     \func{symlink}, \func{sysconf}, \func{tcdrain}, \func{tcflow},
2294     \func{tcflush}, \func{tcgetattr}, \func{tcgetgrp}, \func{tcsendbreak},
2295     \func{tcsetattr}, \func{tcsetpgrp}, \func{time}, \func{timer\_getoverrun},
2296     \func{timer\_gettime}, \func{timer\_settime}, \func{times}, \func{umask},
2297     \func{uname}, \func{unlink}, \func{utime}, \func{wait}, \func{waitpid},
2298     \func{write}.
2299   \end{minipage} 
2300   \normalsize 
2301   \caption{Elenco delle funzioni sicure secondo lo standard POSIX
2302     1003.1-2003.}
2303   \label{fig:sig_safe_functions}
2304 \end{figure}
2305
2306 \index{funzioni~sicure|)}
2307
2308 Per questo motivo è opportuno mantenere al minimo indispensabile le operazioni
2309 effettuate all'interno di un gestore di segnali, qualora si debbano compiere
2310 operazioni complesse è sempre preferibile utilizzare la tecnica in cui si usa
2311 il gestore per impostare il valore di una qualche variabile globale, e poi si
2312 eseguono le operazioni complesse nel programma verificando (con tutti gli
2313 accorgimenti visti in precedenza) il valore di questa variabile tutte le volte
2314 che si è rilevata una interruzione dovuta ad un segnale.
2315
2316
2317 \subsection{I segnali real-time}
2318 \label{sec:sig_real_time}
2319
2320 Lo standard POSIX.1b, nel definire una serie di nuove interfacce per i servizi
2321 real-time, ha introdotto una estensione del modello classico dei segnali che
2322 presenta dei significativi miglioramenti,\footnote{questa estensione è stata
2323   introdotta in Linux a partire dal kernel 2.1.43(?), e dalle \acr{glibc}
2324   2.1(?).} in particolare sono stati superati tre limiti fondamentali dei
2325 segnali classici:
2326 \begin{basedescript}{\desclabelwidth{1cm}\desclabelstyle{\nextlinelabel}}
2327 \item[I segnali non sono accumulati] 
2328   se più segnali vengono generati prima dell'esecuzione di un gestore
2329   questo sarà eseguito una sola volta, ed il processo non sarà in grado di
2330   accorgersi di quante volte l'evento che ha generato il segnale è accaduto;
2331 \item[I segnali non trasportano informazione]   
2332   i segnali classici non prevedono altra informazione sull'evento
2333   che li ha generati se non il fatto che sono stati emessi (tutta
2334   l'informazione che il kernel associa ad un segnale è il suo numero);
2335 \item[I segnali non hanno un ordine di consegna] 
2336   l'ordine in cui diversi segnali vengono consegnati è casuale e non
2337   prevedibile. Non è possibile stabilire una priorità per cui la reazione a
2338   certi segnali ha la precedenza rispetto ad altri.
2339 \end{basedescript}
2340
2341
2342 Per poter superare queste limitazioni lo standard ha introdotto delle nuove
2343 caratteristiche, che sono state associate ad una nuova classe di segnali, che
2344 vengono chiamati \textsl{segnali real-time}, in particolare le funzionalità
2345 aggiunte sono:
2346
2347 \begin{enumerate}
2348 \item i segnali sono inseriti in una coda che permette di consegnare istanze
2349   multiple dello stesso segnale qualora esso venga inviato più volte prima
2350   dell'esecuzione del gestore; si assicura così che il processo riceva un
2351   segnale per ogni occorrenza dell'evento che lo genera.
2352 \item è stata introdotta una priorità nella consegna dei segnali: i segnali
2353   vengono consegnati in ordine a seconda del loro valore, partendo da quelli
2354   con un numero minore, che pertanto hanno una priorità maggiore.
2355 \item è stata introdotta la possibilità di restituire dei dati al gestore,
2356   attraverso l'uso di un apposito campo \var{si\_value} nella struttura
2357   \struct{siginfo\_t}, accessibile tramite gestori di tipo
2358   \var{sa\_sigaction}.
2359 \end{enumerate}
2360
2361 Queste nuove funzionalità (eccetto l'ultima, che, come vedremo, è parzialmente
2362 disponibile anche con i segnali ordinari) si applicano solo ai nuovi segnali
2363 real-time; questi ultimi sono accessibili in un range di valori specificati
2364 dalle due macro \const{SIGRTMIN} e \const{SIGRTMAX},\footnote{in Linux di
2365   solito (cioè sulla piattaforma i386) il primo valore è 33, ed il secondo
2366   \code{\_NSIG-1}, che di norma è 64, per un totale di 32 segnali disponibili,
2367   contro gli almeno 8 richiesti da POSIX.1b.} che specificano il numero minimo
2368 e massimo associato ad un segnale real-time.
2369
2370 I segnali con un numero più basso hanno una priorità maggiore e vengono
2371 consegnati per primi, inoltre i segnali real-time non possono interrompere
2372 l'esecuzione di un gestore di un segnale a priorità più alta; la loro azione
2373 predefinita è quella di terminare il programma.  I segnali ordinari hanno
2374 tutti la stessa priorità, che è più alta di quella di qualunque segnale
2375 real-time.
2376
2377 Si tenga presente che questi nuovi segnali non sono associati a nessun evento
2378 specifico, a meno di non utilizzarli in meccanismi di notifica come quelli per
2379 l'I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io}) o per le code di
2380 messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}); pertanto devono essere
2381 inviati esplicitamente. 
2382
2383 Inoltre, per poter usufruire della capacità di restituire dei dati, i relativi
2384 gestori devono essere installati con \func{sigaction}, specificando per
2385 \var{sa\_flags} la modalità \const{SA\_SIGINFO} che permette di utilizzare la
2386 forma estesa \var{sa\_sigaction} (vedi sez.~\ref{sec:sig_sigaction}).  In
2387 questo modo tutti i segnali real-time possono restituire al gestore una serie
2388 di informazioni aggiuntive attraverso l'argomento \struct{siginfo\_t}, la cui
2389 definizione è stata già vista in fig.~\ref{fig:sig_siginfo_t}, nella
2390 trattazione dei gestori in forma estesa.
2391
2392 In particolare i campi utilizzati dai segnali real-time sono \var{si\_pid} e
2393 \var{si\_uid} in cui vengono memorizzati rispettivamente il \acr{pid} e
2394 l'user-ID effettivo del processo che ha inviato il segnale, mentre per la
2395 restituzione dei dati viene usato il campo \var{si\_value}.
2396
2397 Questo è una \ctyp{union} di tipo \struct{sigval\_t} (la sua definizione è in
2398 fig.~\ref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico,
2399 se usata nella forma \var{sival\_int}, o un indirizzo, se usata nella forma
2400 \var{sival\_ptr}. L'unione viene usata dai segnali real-time e da vari
2401 meccanismi di notifica\footnote{un campo di tipo \struct{sigval\_t} è presente
2402   anche nella struttura \struct{sigevent} che viene usata dai meccanismi di
2403   notifica come quelli per l'I/O asincrono (vedi
2404   sez.~\ref{sec:file_asyncronous_io}) o le code di messaggi POSIX (vedi
2405   sez.~\ref{sec:ipc_posix_mq}).} per restituire dati al gestore del segnale; in
2406 alcune definizioni essa viene identificata anche come \code{union sigval}.
2407
2408 \begin{figure}[!htb]
2409   \footnotesize \centering
2410   \begin{minipage}[c]{15cm}
2411     \includestruct{listati/sigval_t.h}
2412   \end{minipage} 
2413   \normalsize 
2414   \caption{La unione \structd{sigval\_t}.}
2415   \label{fig:sig_sigval}
2416 \end{figure}
2417
2418 A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
2419 inviare segnali real-time, poiché non è in grado di fornire alcun valore
2420 per \struct{sigval\_t}; per questo motivo lo standard ha previsto una nuova
2421 funzione, \funcd{sigqueue}, il cui prototipo è:
2422 \begin{prototype}{signal.h}
2423   {int sigqueue(pid\_t pid, int signo, const sigval\_t value)}
2424   
2425   Invia il segnale \param{signo} al processo \param{pid}, restituendo al
2426   gestore il valore \param{value}.
2427   
2428   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
2429     errore, nel qual caso \var{errno} assumerà uno dei valori:
2430   \begin{errlist}
2431   \item[\errcode{EAGAIN}] La coda è esaurita, ci sono già \const{SIGQUEUE\_MAX}
2432     segnali in attesa si consegna.
2433   \item[\errcode{EPERM}] Non si hanno privilegi appropriati per inviare il
2434     segnale al processo specificato.
2435   \item[\errcode{ESRCH}] Il processo \param{pid} non esiste.
2436   \item[\errcode{EINVAL}] Si è specificato un valore non valido per
2437     \param{signo}.
2438   \end{errlist}
2439   ed inoltre \errval{ENOMEM}.}
2440 \end{prototype}
2441
2442 Il comportamento della funzione è analogo a quello di \func{kill}, ed i
2443 privilegi occorrenti ad inviare il segnale ad un determinato processo sono gli
2444 stessi; un valore nullo di \param{signo} permette di verificare le condizioni
2445 di errore senza inviare nessun segnale.
2446
2447 Se il segnale è bloccato la funzione ritorna immediatamente, se si è
2448 installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili,
2449 (vale a dire che c'è posto\footnote{la profondità della coda è indicata dalla
2450   costante \const{SIGQUEUE\_MAX}, una della tante costanti di sistema definite
2451   dallo standard POSIX che non abbiamo riportato esplicitamente in
2452   sez.~\ref{sec:sys_limits}; il suo valore minimo secondo lo standard,
2453   \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux questo è uno
2454   dei parametri del kernel impostabili sia con \func{sysctl}, che scrivendolo
2455   direttamente in \file{/proc/sys/kernel/rtsig-max}, il valore predefinito è
2456   di 1024.} nella coda dei segnali real-time) esso viene inserito e diventa
2457 pendente; una volta consegnato riporterà nel campo \var{si\_code} di
2458 \struct{siginfo\_t} il valore \const{SI\_QUEUE} e il campo \var{si\_value}
2459 riceverà quanto inviato con \param{value}. Se invece si è installato un
2460 gestore nella forma classica il segnale sarà generato, ma tutte le
2461 caratteristiche tipiche dei segnali real-time (priorità e coda) saranno perse.
2462
2463 Lo standard POSIX.1b definisce inoltre delle nuove funzioni che permettono di
2464 gestire l'attesa di segnali specifici su una coda, esse servono in particolar
2465 modo nel caso dei thread, in cui si possono usare i segnali real-time come
2466 meccanismi di comunicazione elementare; la prima di queste funzioni è
2467 \funcd{sigwait}, il cui prototipo è:
2468 \begin{prototype}{signal.h}
2469   {int sigwait(const sigset\_t *set, int *sig)}
2470   
2471   Attende che uno dei segnali specificati in \param{set} sia pendente.
2472   
2473   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
2474     errore, nel qual caso \var{errno} assumerà uno dei valori:
2475   \begin{errlist}
2476   \item[\errcode{EINTR}] La funzione è stata interrotta.
2477   \item[\errcode{EINVAL}] Si è specificato un valore non valido per
2478     \param{set}.
2479   \end{errlist}
2480   ed inoltre \errval{EFAULT}.}
2481 \end{prototype}
2482
2483 La funzione estrae dall'insieme dei segnali pendenti uno qualunque dei segnali
2484 specificati da \param{set}, il cui valore viene restituito in \param{sig}.  Se
2485 sono pendenti più segnali, viene estratto quello a priorità più alta (cioè con
2486 il numero più basso). Se, nel caso di segnali real-time, c'è più di un segnale
2487 pendente, ne verrà estratto solo uno. Una volta estratto il segnale non verrà
2488 più consegnato, e se era in una coda il suo posto sarà liberato.  Se non c'è
2489 nessun segnale pendente il processo viene bloccato fintanto che non ne arriva
2490 uno.
2491
2492 Per un funzionamento corretto la funzione richiede che alla sua chiamata i
2493 segnali di \param{set} siano bloccati. In caso contrario si avrebbe un
2494 conflitto con gli eventuali gestori: pertanto non si deve utilizzare per
2495 lo stesso segnale questa funzione e \func{sigaction}. Se questo non avviene il
2496 comportamento del sistema è indeterminato: il segnale può sia essere
2497 consegnato che essere ricevuto da \func{sigwait}, il tutto in maniera non
2498 prevedibile.
2499
2500 Lo standard POSIX.1b definisce altre due funzioni, anch'esse usate
2501 prevalentemente con i thread; \funcd{sigwaitinfo} e \funcd{sigtimedwait}, i
2502 relativi prototipi sono:
2503 \begin{functions}
2504   \headdecl{signal.h}   
2505
2506   \funcdecl{int sigwaitinfo(const sigset\_t *set, siginfo\_t *info)}  
2507   
2508   Analoga a \func{sigwait}, ma riceve anche le informazioni associate al
2509   segnale in \param{info}.
2510   
2511   \funcdecl{int sigtimedwait(const sigset\_t *set, siginfo\_t *value, const
2512     struct timespec *info)}
2513   
2514   Analoga a \func{sigwaitinfo}, con un la possibilità di specificare un
2515   timeout in \param{timeout}.
2516
2517   
2518   \bodydesc{Le funzioni restituiscono 0 in caso di successo e $-1$ in caso di
2519     errore, nel qual caso \var{errno} assumerà uno dei valori già visti per
2520     \func{sigwait}, ai quali si aggiunge, per \func{sigtimedwait}:
2521   \begin{errlist}
2522   \item[\errcode{EAGAIN}] Si è superato il timeout senza che un segnale atteso
2523     fosse emesso.
2524   \end{errlist}
2525 }
2526 \end{functions}
2527
2528 Entrambe le funzioni sono estensioni di \func{sigwait}. La prima permette di
2529 ricevere, oltre al numero del segnale, anche le informazioni ad esso associate
2530 tramite \param{info}; in particolare viene restituito il numero del segnale
2531 nel campo \var{si\_signo}, la sua causa in \var{si\_code}, e se il segnale è
2532 stato immesso sulla coda con \func{sigqueue}, il valore di ritorno ad esso
2533 associato viene riportato in \var{si\_value}, che altrimenti è indefinito. 
2534
2535 La seconda è identica alla prima ma in più permette di specificare un timeout,
2536 scaduto il quale ritornerà con un errore. Se si specifica un puntatore nullo
2537 il comportamento sarà identico a \func{sigwaitinfo}, se si specifica un tempo
2538 di timeout nullo, e non ci sono segnali pendenti la funzione ritornerà
2539 immediatamente; in questo modo si può eliminare un segnale dalla coda senza
2540 dover essere bloccati qualora esso non sia presente.
2541
2542 L'uso di queste funzioni è principalmente associato alla gestione dei segnali
2543 con i thread. In genere esse vengono chiamate dal thread incaricato della
2544 gestione, che al ritorno della funzione esegue il codice che usualmente
2545 sarebbe messo nel gestore, per poi ripetere la chiamata per mettersi in attesa
2546 del segnale successivo. Questo ovviamente comporta che non devono essere
2547 installati gestori, che solo il thread di gestione deve usare \func{sigwait} e
2548 che, per evitare che venga eseguita l'azione predefinita, i segnali gestiti in
2549 questa maniera devono essere mascherati per tutti i thread, compreso quello
2550 dedicato alla gestione, che potrebbe riceverlo fra due chiamate successive.
2551
2552
2553
2554
2555 % LocalWords:  kernel POSIX timer shell control ctrl kill raise signal handler
2556 % LocalWords:  reliable unreliable fig race condition sez struct process table
2557 % LocalWords:  delivered pending scheduler sigpending l'I suspend SIGKILL wait
2558 % LocalWords:  SIGSTOP sigaction waitpid dump stack debugger nell'header NSIG
2559 % LocalWords:  tab BSD SUSv SIGHUP PL Hangup SIGINT Interrupt SIGQUIT Quit AEF
2560 % LocalWords:  SIGILL SIGABRT abort SIGFPE SIGSEGV SIGPIPE SIGALRM alarm SIGUSR
2561 % LocalWords:  SIGTERM SIGCHLD SIGCONT SIGTSTP SIGTTIN SIGTTOU SIGBUS bad SL of
2562 % LocalWords:  memory access SIGPOLL Pollable event Sys SIGIO SIGPROF profiling
2563 % LocalWords:  SIGSYS SVID SIGTRAP breakpoint SIGURG urgent socket Virtual IOT
2564 % LocalWords:  clock SIGXCPU SIGXFSZ SIGIOT trap SIGEMT SIGSTKFLT SIGCLD SIGPWR
2565 % LocalWords:  SIGINFO SIGLOST lock NFS SIGWINCH Sun SIGUNUSED fault point heap
2566 % LocalWords:  exception l'overflow illegal instruction overflow segment error
2567 % LocalWords:  violation system call interrupt INTR hang SIGVTALRM virtual SUSP
2568 % LocalWords:  profilazione fcntl descriptor sleep interactive Broken FIFO lost
2569 % LocalWords:  EPIPE Resource advisory client limit exceeded size window change
2570 % LocalWords:  strsignal psignal SOURCE strerror string char int signum perror
2571 % LocalWords:  void sig const sys siglist L'array decr fork exec DFL IGN ioctl
2572 % LocalWords:  EINTR glibc TEMP FAILURE RETRY expr multitasking SVr sighandler
2573 % LocalWords:  ERR libc bsd sysv XOPEN EINVAL pid errno ESRCH EPERM getpid init
2574 % LocalWords:  killpg pidgrp group unistd unsigned seconds all' setitimer which
2575 % LocalWords:  itimerval value ovalue EFAULT ITIMER it interval timeval ms VIRT
2576 % LocalWords:  getitimer stdlib stream atexit exit usleep long usec nanosleep
2577 % LocalWords:  timespec req rem HZ scheduling SCHED RR SigHand forktest WNOHANG
2578 % LocalWords:  deadlock longjmp setjmp sigset sigemptyset sigfillset sigaddset
2579 % LocalWords:  sigdelset sigismember act oldact restorer mask NOCLDSTOP ONESHOT
2580 % LocalWords:  RESETHAND RESTART NOMASK NODEFER ONSTACK sigcontext union signo
2581 % LocalWords:  siginfo bits uid addr fd inline like blocked atomic sigprocmask
2582 % LocalWords:  how oldset BLOCK UNBLOCK SETMASK sigsuspend sigaltstack malloc
2583 % LocalWords:  SIGSTKSZ MINSIGSTKSZ ss oss ENOMEM flags DISABLE sp setrlimit LB
2584 % LocalWords:  RLIMIT rlim sigsetjmp siglongjmp sigjmp buf env savesigs jmp ptr
2585 % LocalWords:  SIGRTMIN SIGRTMAX sigval sigevent sigqueue EAGAIN sysctl safe
2586 % LocalWords:  QUEUE thread sigwait sigwaitinfo sigtimedwait info DEF SLB bind
2587 % LocalWords:  function accept return cfgetispeed cfgetospeed cfsetispeed chdir
2588 % LocalWords:  cfsetospeed chmod chown gettime close connect creat dup execle
2589 % LocalWords:  execve fchmod fchown fdatasync fpathconf fstat fsync ftruncate
2590 % LocalWords:  getegid geteuid getgid getgroups getpeername getpgrp getppid sem
2591 % LocalWords:  getsockname getsockopt getuid listen lseek lstat mkdir mkfifo
2592 % LocalWords:  pathconf poll posix pselect read readlink recv recvfrom recvmsg
2593 % LocalWords:  rename rmdir select send sendmsg sendto setgid setpgid setsid
2594 % LocalWords:  setsockopt setuid shutdown sigpause socketpair stat symlink
2595 % LocalWords:  sysconf tcdrain tcflow tcflush tcgetattr tcgetgrp tcsendbreak
2596 % LocalWords:  tcsetattr tcsetpgrp getoverrun times umask uname unlink utime
2597 % LocalWords:  write sival
2598
2599
2600 %%% Local Variables: 
2601 %%% mode: latex
2602 %%% TeX-master: "gapil"
2603 %%% End: