4 I segnali sono il primo e più semplice meccanismo di comunicazione nei
5 confronti dei processi. Non portano con sé nessuna informazione che non sia il
6 loro tipo; si tratta in sostanza di un'interruzione software portata ad un
9 In genere essi vengono usati dal kernel per riportare ai processi situazioni
10 eccezionali (come errori di accesso, eccezioni aritmetiche, etc.) ma possono
11 anche essere usati come forma elementare di comunicazione fra processi (ad
12 esempio vengono usati per il controllo di sessione), per notificare eventi
13 (come la terminazione di un processo figlio), ecc.
15 In questo capitolo esamineremo i vari aspetti della gestione dei segnali,
16 partendo da una introduzione relativa ai concetti base con cui essi vengono
17 realizzati, per poi affrontarne la classificazione a secondo di uso e modalità
18 di generazione fino ad esaminare in dettaglio funzioni e le metodologie di
23 \section{Introduzione}
26 In questa sezione esamineremo i concetti generali relativi ai segnali, vedremo
27 le loro caratteristiche di base, introdurremo le nozioni di fondo relative
28 all'architettura del funzionamento dei segnali e alle modalità con cui il
29 sistema gestisce l'interazione fra di essi ed i processi.
32 \subsection{I concetti base}
35 Come il nome stesso indica i segnali sono usati per notificare ad un processo
36 l'occorrenza di un qualche evento. Gli eventi che possono generare un segnale
37 sono vari; un breve elenco di possibili cause per l'emissione di un segnale è
41 \item un errore del programma, come una divisione per zero o un tentativo di
42 accesso alla memoria fuori dai limiti validi.
43 \item la terminazione di un processo figlio.
44 \item la scadenza di un timer o di un allarme.
45 \item il tentativo di effettuare un'operazione di input/output che non può
47 \item una richiesta dell'utente di terminare o fermare il programma. In genere
48 si realizza attraverso un segnale mandato dalla shell in corrispondenza
49 della pressione di tasti del terminale come \code{C-c} o
50 \code{C-z}.\footnote{indichiamo con \code{C-x} la pressione simultanea al
51 tasto \code{x} del tasto control (ctrl in molte tastiere).}
52 \item l'esecuzione di una \func{kill} o di una \func{raise} da parte del
53 processo stesso o di un'altro (solo nel caso della \func{kill}).
56 Ciascuno di questi eventi (compresi gli ultimi due che pure sono controllati
57 dall'utente o da un altro processo) comporta l'intervento diretto da parte del
58 kernel che causa la generazione un particolare tipo di segnale.
60 Quando un processo riceve un segnale, invece del normale corso del programma,
61 viene eseguita una azione di default o una apposita routine di gestione (il
62 cosiddetto \textit{signal handler} o \textsl{manipolatore}) che può essere
63 stata specificata dall'utente (nel qual caso si dice che si
64 \textsl{intercetta} il segnale).
67 \subsection{Le modalità di funzionamento}
68 \label{sec:sig_semantics}
70 Negli anni il comportamento del sistema in risposta ai segnali è stato
71 modificato in vari modi nelle differenti implementazioni di Unix. Si possono
72 individuare due tipologie fondamentali di comportamento dei segnali (dette
73 semantiche) che vengono chiamate rispettivamente semantica \textsl{affidabile}
74 (o \textit{reliable}) e semantica \textsl{inaffidabile} (o
77 Nella semantica \textsl{inaffidabile} (quella implementata dalle prime
78 versioni di Unix) la routine di gestione del segnale specificata dall'utente
79 non resta attiva una volta che è stata eseguita; è perciò compito dell'utente
80 stesso ripetere l'installazione della stessa all'interno della routine di
81 gestione, in tutti i casi in cui si vuole che il manipolatore esterno resti
84 In questo caso è possibile una situazione in cui i segnali possono essere
85 perduti. Si consideri il seguente segmento di codice, in cui la prima
86 operazione del manipolatore è quella di reinstallare se stesso:
88 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
89 int sig_handler(); /* handler function */
91 signal(SIGINT, sig_handler); /* establish handler */
96 signal(SIGINT, sig_handler); /* restablish handler */
97 ... /* process signal */
101 se un secondo segnale arriva prima che il manipolatore invocato dal primo
102 abbia eseguito la reinstallazione di se stesso il segnale può essere perso o
103 causare il comportamento originale assegnato al segnale (in genere la
104 terminazione del processo).
106 Questa è la ragione per cui l'implementazione dei segnali secondo questa
107 semantica viene chiamata \textsl{inaffidabile}; infatti la ricezione del
108 segnale e la reinstallazione del suo manipolatore non sono operazioni
109 atomiche, e sono sempre possibili delle race condition (sull'argomento vedi
110 quanto detto in \secref{sec:proc_multi_prog}).
112 Un'altro problema è che in questa semantica non esiste un modo per bloccare i
113 segnali quando non si vuole che arrivino; i processi possono ignorare il
114 segnale, ma non è possibile istruire il sistema a non fare nulla in occasione
115 di un segnale, pur mantenendo memoria del fatto che è avvenuto.
117 % Un caso classico in cui si incontra questo problema, è quello in cui si usa il
118 % manipolatore per settare un flag che riporta al processo l'occorrenza del
119 % segnale, così che questo possa prendere provvedimenti al di fuori del
120 % manipolatore. Si consideri il seguente segmento di codice il cui scopo sarebbe
121 % quello di fermare il processo fino all'occorrenza di un opportuno segnale:
124 % \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
125 % int signal_flag = 0;
128 % int sig_handler(); /* handler function */
130 % signal(SIGINT, sig_handler); /* establish handler */
132 % while(signal_flag == 0) { /* while flag is zero */
133 % pause(); /* go to sleep */
139 % signal(SIGINT, sig_handler); /* restablish handler */
140 % signal_flag = 1; /* set flag */
144 % l'idea è che quando il processo trova il flag a zero viene messo in sleep e
145 % verrà risvegliato solo dalla ricezione di un segnale. Il manipolatore si
146 % limita in questo caso a settare il flag a uno; all'uscita dal manipolatore la
147 % chiamata a \func{pause} è interrotta ed il processo viene risvegliato e
148 % riprende l'esecuzione all'istruzione successiva, ma essendo cambiato il flag
149 % la condizione non è più soddisfatta e il programma prosegue.
151 % Il problema con l'implementazione inaffidabile è che niente ci garantisce che
152 % il segnale arrivi fra la valutazione della condizione del \code{while} e la
153 % chiamata a \func{pause}, nel qual caso, se il segnale non viene più generato,
154 % il processo resterà in sleep permanentemente.
156 % Questo ci mostra ad esempio come con la semantica inaffidabile non esista una
157 % modalità semplice per ottenere una operazione di attesa mandando in stato di
158 % sleep (vedi \ref{sec:proc_sched}) un processo fino all'arrivo di un segnale.
160 Nella semantica \textsl{affidabile} (quella utilizzata da Linux e da ogni Unix
161 moderno) il manipolatore una volta installato resta attivo e non si hanno
162 tutti i problemi precedenti. In questa semantica i segnali vengono
163 \textsl{generati} dal kernel per un processo all'occorrenza dell'evento che
164 causa il segnale. In genere questo viene fatto dal kernel settando l'apposito
165 campo della \var{task\_struct} del processo nella process table (si veda
166 \figref{fig:proc_task_struct}).
168 Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
169 \textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
170 per tutto il tempo che passa fra la generazione del segnale e la sua consegna
171 esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
172 procedura viene effettuata dallo scheduler quando, riprendendo l'esecuzione
173 del processo in questione, verifica la presenza del segnale nella
174 \var{task\_struct} e mette in esecuzione il manipolatore.
176 In questa semantica un processo ha la possibilità di bloccare la consegna dei
177 segnali, in questo caso, se l'azione per il suddetto segnale non è quella di
178 ignorarlo, il segnale resta \textsl{pendente} fintanto che il processo non lo
179 sblocca (nel qual caso viene consegnato) o setta l'azione di default per
182 Si tenga presente che il kernel stabilisce cosa fare con un segnale che è
183 stato bloccato al momento della consegna, non quando viene generato; questo
184 consente di cambiare l'azione per il segnale prima che esso venga consegnato,
185 e si può usare la funzione \func{sigpending} (vedi
186 \secref{sec:sig_sigpending}) per determinare quali segnali sono bloccati e
190 \subsection{Tipi di segnali}
191 \label{sec:sig_types}
193 In generale gli eventi che generano segnali si possono dividere in tre
194 categorie principali: errori, eventi esterni e richieste esplicite.
196 Un errore significa che un programma ha fatto qualcosa di sbagliato e non può
197 continuare ad essere eseguito. Non tutti gli errori causano dei segnali, in
198 genere la condizione di errore più comune comporta la restituzione di un
199 codice di errore da parte di una funzione di libreria, sono gli errori che
200 possono avvenire ovunque in un programma che causano l'emissione di un
201 segnale, come le divisioni per zero o l'uso di indirizzi di memoria non validi.
203 Un evento esterno ha in genere a che fare con l'I/O o con altri processi;
204 esempi di segnali di questo tipo sono quelli legati all'arrivo di dati di
205 input, scadenze di un timer, terminazione di processi figli.
207 Una richiesta esplicita significa l'uso di una chiamata di sistema (come
208 \func{kill} o \func{raise}) per la generazione di un segnale, cosa che
209 viene fatta usualmente dalla shell quando l'utente invoca la sequenza di tasti
210 di stop o di suspend, ma può essere pure inserita all'interno di un programma.
212 Si dice poi che i segnali possono essere \textsl{asincroni} o
213 \textsl{sincroni}. Un segnale \textsl{sincrono} è legato ad una azione
214 specifica di un programma ed è inviato (a meno che non sia bloccato) durante
215 tale azione; molti errori generano segnali \textsl{sincroni}, così come la
216 richiesta esplicita da parte del processo tramite le chiamate al sistema.
217 Alcuni errori come la divisione per zero non sono completamente sincroni e
218 possono arrivare dopo qualche istruzione.
220 I segnali \textsl{asincroni} sono generati da eventi fuori dal controllo del
221 processo che li riceve, e arrivano in tempi impredicibili nel corso
222 dell'esecuzione del programma. Eventi esterni come la terminazione di un
223 processo figlio generano segnali \textsl{asincroni}, così come le richieste di
224 generazione di un segnale effettuate da altri processi.
226 In generale un tipo di segnale o è sincrono o è asincrono, salvo il caso in
227 cui esso sia generato attraverso una richiesta esplicita tramite chiamata al
228 sistema, nel qual caso qualunque tipo di segnale (quello scelto nella
229 chiamata) può diventare sincrono o asincrono a seconda che sia generato
230 internamente o esternamente al processo.
233 \subsection{La notifica dei segnali}
234 \label{sec:sig_notification}
236 Come accennato quando un segnale viene generato, se la sua azione di default
237 non è quella di essere ignorato, il kernel prende nota del fatto nella
238 \var{task\_struct} del processo; si dice così che il segnale diventa
239 \textsl{pendente} (o \textit{pending}), e rimane tale fino al momento in cui
240 verrà notificato al processo (o verrà specificata come azione di default
241 quella di ignorarlo).
243 Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
244 avviene non appena questo viene rimesso in esecuzione dallo scheduler che
245 esegue l'azione specificata. Questo a meno che il segnale in questione non sia
246 stato bloccato prima della notifica, nel qual caso l'invio non avviene ed il
247 segnale resta \textsl{pendente} indefinitamente. Quando lo si sblocca il
248 segnale \textsl{pendente} sarà subito notificato.
250 Si ricordi però che se l'azione specificata per un segnale è quella di essere
251 ignorato questo sarà scartato immediatamente al momento della sua generazione,
252 e questo anche se in quel momento il segnale è bloccato (perché ciò che viene
253 bloccata è la notifica). Per questo motivo un segnale, fintanto che viene
254 ignorato, non sarà mai notificato, anche se è stato bloccato ed in seguito si
255 è specificata una azione diversa (nel qual caso solo i segnali successivi alla
256 nuova specificazione saranno notificati).
258 Una volta che un segnale viene notificato (che questo avvenga subito o dopo
259 una attesa più o meno lunga) viene eseguita l'azione specificata per il
260 segnale. Per alcuni segnali (\macro{SIGKILL} e \macro{SIGSTOP}) questa azione
261 è fissa e non può essere cambiata, ma per tutti gli altri si può selezionare
262 una delle tre possibilità seguenti:
265 \item ignorare il segnale.
266 \item catturare il segnale, ed utilizzare il manipolatore specificato.
267 \item accettare l'azione di default per quel segnale.
270 Un programma può specificare queste scelte usando le due funzioni
271 \func{signal} e \func{sigaction} (vedi \secref{sec:sig_signal} e
272 \secref{sec:sig_sigaction}). Se si è installato un manipolatore sarà
273 quest'ultimo ad essere eseguito alla notifica del segnale. Inoltre il sistema
274 farà si che mentre viene eseguito il manipolatore di un segnale, quest'ultimo
275 venga automaticamente bloccato (così si possono evitare race condition).
277 Nel caso non sia stata specificata un'azione, viene utilizzata l'azione
278 standard che (come vedremo in \secref{sec:sig_standard}) è propria di ciascun
279 segnale; nella maggior parte dei casi essa porta alla terminazione del
280 processo, ma alcuni segnali che rappresentano eventi innocui vengono ignorati.
282 Quando un segnale termina un processo, il padre può determinare la causa della
283 terminazione esaminando il codice di stato riportato delle funzioni
284 \func{wait} e \func{waitpid} (vedi \secref{sec:proc_wait}); questo è il modo
285 in cui la shell determina i motivi della terminazione di un programma e scrive
286 un eventuale messaggio di errore.
288 I segnali che rappresentano errori del programma (divisione per zero o
289 violazioni di accesso) hanno anche la caratteristica di scrivere un file di
290 \textit{core dump} che registra lo stato del processo (ed in particolare della
291 memoria e dello stack) prima della terminazione. Questo può essere esaminato
292 in seguito con un debugger per investigare sulla causa dell'errore. Lo stesso
293 avviene se i suddetti segnale vengono generati con una \func{kill}.
296 \section{La classificazione dei segnali}
297 \label{sec:sig_classification}
299 Esamineremo in questa sezione quali sono i vari segnali definiti nel sistema,
300 le loro caratteristiche e tipologia, le varie macro e costanti che permettono
301 di identificarli, e le funzioni che ne stampano la descrizione.
304 \subsection{I segnali standard}
305 \label{sec:sig_standard}
307 Ciascun segnale è identificato rispetto al sistema da un numero, ma l'uso
308 diretto di questo numero da parte dei programmi è da evitare, in quanto esso
309 può variare a seconda dell'implementazione del sistema, e nel caso si Linux,
310 anche a seconda dell'architettura hardware.
311 Per questo motivo ad ogni segnale viene associato un nome, definendo con una
312 macro di preprocessore una costante uguale al suddetto numero. Sono questi
313 nomi, che sono standardizzati e sostanzialmente uniformi rispetto alle varie
314 implementazioni, che si devono usare nei programmi. Tutti i nomi e le funzioni
315 che concernono i segnali sono definiti nell'header di sistema \file{signal.h}.
317 Il numero totale di segnali presenti è dato dalla macro \macro{NSIG}, e dato
318 che i numeri dei segnali sono allocati progressivamente, essa corrisponde
319 anche al successivo del valore numerico assegnato all'ultimo segnale definito.
320 In \tabref{tab:sig_signal_list} si è riportato l'elenco completo dei segnali
321 definiti in Linux (estratto dalle man page), comparati con quelli definiti in
327 \begin{tabular}[c]{|c|p{8cm}|}
329 \textbf{Sigla} & \textbf{Significato} \\
332 A & L'azione di default è terminare il processo. \\
333 B & L'azione di default è ignorare il segnale. \\
334 C & L'azione di default è terminare il processo e scrivere un \textit{core
336 D & L'azione di default è fermare il processo. \\
337 E & Il segnale non può essere intercettato. \\
338 F & Il segnale non può essere ignorato.\\
341 \caption{Legenda delle azioni di default dei segnali riportate in
342 \tabref{tab:sig_signal_list}.}
343 \label{tab:sig_action_leg}
346 In \tabref{tab:sig_signal_list} si sono anche riportate le azioni di default
347 di ciascun segnale (riassunte con delle lettere, la cui legenda completa è in
348 \tabref{tab:sig_action_leg}), quando nessun manipolatore è installato un
349 segnale può essere ignorato o causare la terminazione del processo. Nella
350 colonna standard sono stati indicati anche gli standard in cui ciascun segnale
351 è definito, secondo lo schema di \tabref{tab:sig_standard_leg}.
357 \begin{tabular}[c]{|c|l|}
359 \textbf{Sigla} & \textbf{Standard} \\
368 \caption{Legenda dei valori della colonna \textbf{Standard} di
369 \tabref{tab:sig_signal_list}.}
370 \label{tab:sig_standard_leg}
373 In alcuni casi alla terminazione del processo è associata la creazione di un
374 file (posto nella directory corrente del processo e chiamato \file{core}) su
375 cui viene salvata un'immagine della memoria del processo (il cosiddetto
376 \textit{core dump}), che può essere usata da un debugger per esaminare lo
377 stato dello stack e delle variabili al momento della ricezione del segnale.
382 \begin{tabular}[c]{|l|c|c|p{8cm}|}
384 \textbf{Segnale}&\textbf{Standard}&\textbf{Azione}&\textbf{Descrizione} \\
387 \macro{SIGHUP} &PL & A & Hangup o fine del processo di controllo \\
388 \macro{SIGINT} &PL & A & Interrupt da tastiera (\cmd{C-c}) \\
389 \macro{SIGQUIT} &PL & C & Quit da tastiera (\cmd{C-y}) \\
390 \macro{SIGILL} &PL & C & Istruzione illegale \\
391 \macro{SIGABRT} &PL & C & Segnale di abort da \func{abort} \\
392 \macro{SIGFPE} &PL & C & Errore aritmetico \\
393 \macro{SIGKILL} &PL &AEF& Segnale di terminazione forzata \\
394 \macro{SIGSEGV} &PL & C & Errore di accesso in memoria \\
395 \macro{SIGPIPE} &PL & A & Pipe spezzata \\
396 \macro{SIGALRM} &PL & A & Segnale del timer da \func{alarm} \\
397 \macro{SIGTERM} &PL & A & Segnale di terminazione \verb|C-\| \\
398 \macro{SIGUSR1} &PL & A & Segnale utente numero 1 \\
399 \macro{SIGUSR2} &PL & A & Segnale utente numero 2 \\
400 \macro{SIGCHLD} &PL & B & Figlio terminato o fermato \\
401 \macro{SIGCONT} &PL & & Continua se fermato \\
402 \macro{SIGSTOP} &PL &DEF& Ferma il processo \\
403 \macro{SIGTSTP} &PL & D & Stop typed at tty \\
404 \macro{SIGTTIN} &PL & D & Input sul terminale per un processo
406 \macro{SIGTTOU} &PL & D & Output sul terminale per un processo
408 \macro{SIGBUS} &SL & C & Errore sul bus (bad memory access) \\
409 \macro{SIGPOLL} &SL & A & Pollable event (Sys V).
410 Sinonimo di \macro{SIGIO} \\
411 \macro{SIGPROF} &SL & A & Timer del profiling scaduto \\
412 \macro{SIGSYS} &SL & C & Bad argument to routine (SVID) \\
413 \macro{SIGTRAP} &SL & C & Trace/breakpoint trap \\
414 \macro{SIGURG} &SLB& B & Urgent condition on socket \\
415 \macro{SIGVTALRM}&SLB& A & Virtual alarm clock \\
416 \macro{SIGXCPU} &SLB& C & Ecceduto il limite sul CPU time \\
417 \macro{SIGXFSZ} &SLB& C & Ecceduto il limite sulla dimensione dei file \\
418 \macro{SIGIOT} &L & C & IOT trap. A synonym for \macro{SIGABRT} \\
419 \macro{SIGEMT} &L & & \\
420 \macro{SIGSTKFLT}&L & A & Stack fault on coprocessor \\
421 \macro{SIGIO} &LB & A & I/O now possible (4.2 BSD) \\
422 \macro{SIGCLD} &L & & A synonym for \macro{SIGCHLD} \\
423 \macro{SIGPWR} &L & A & Fallimento dell'alimentazione \\
424 \macro{SIGINFO} &L & & A synonym for \macro{SIGPWR} \\
425 \macro{SIGLOST} &L & A & Perso un lock sul file (per NFS) \\
426 \macro{SIGWINCH} &LB & B & Window resize signal (4.3 BSD, Sun) \\
427 \macro{SIGUNUSED}&L & A & Unused signal (will be SIGSYS) \\
430 \caption{Lista dei segnali in Linux.}
431 \label{tab:sig_signal_list}
434 La descrizione dettagliata del significato dei vari segnali, raggruppati per
435 tipologia, verrà affrontate nei paragrafi successivi.
438 \subsection{Segnali di errore di programma}
439 \label{sec:sig_prog_error}
441 Questi segnali sono generati quando il sistema, o in certi casi direttamente
442 l'hardware (come per i page fault non validi) rileva un qualche errore
443 insanabile nel programma in esecuzione. In generale la generazione di questi
444 segnali significa che il programma ha dei gravi problemi (ad esempio ha
445 dereferenziato un puntatore non valido o ha eseguito una operazione aritmetica
446 proibita) e l'esecuzione non può essere proseguita.
448 In genere si intercettano questi segnali per permettere al programma di
449 terminare in maniera pulita, ad esempio per ripristinare i settaggi della
450 console o eliminare i file di lock prima dell'uscita. In questo caso il
451 manipolatore deve concludersi ripristinando l'azione di default e rialzando il
452 segnale, in questo modo il programma si concluderà senza effetti spiacevoli,
453 ma riportando lo stesso stato di uscita che avrebbe avuto se il manipolatore
456 L'azione di default per tutti questi segnali è causare la terminazione del
457 processo che li ha causati. In genere oltre a questo il segnale provoca pure
458 la registrazione su disco di un file di \textit{core dump} che viene scritto
459 in un file \file{core} nella directory corrente del processo al momento
460 dell'errore, che il debugger può usare per ricostruire lo stato del programma
461 al momento della terminazione.
464 \begin{basedescript}{\desclabelwidth{2.0cm}}
465 \item[\macro{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome
466 derivi da \textit{floating point exception} si applica a tutti gli errori
467 aritmetici compresa la divisione per zero e l'overflow.
469 Se il manipolatore ritorna il comportamento del processo è indefinito, ed
470 ignorare questo segnale può condurre ad un loop infinito.
472 % Per questo segnale le cose sono complicate dal fatto che possono esserci
473 % molte diverse eccezioni che \texttt{SIGFPE} non distingue, mentre lo
474 % standard IEEE per le operazioni in virgola mobile definisce varie eccezioni
475 % aritmetiche e richiede che esse siano notificate.
477 \item[\macro{SIGILL}] Il nome deriva da \textit{illegal instruction},
478 significa che il programma sta cercando di eseguire una istruzione
479 privilegiata o inesistente, in generale del codice illegale. Poiché il
480 compilatore del C genera del codice valido si ottiene questo segnale se il
481 file eseguibile è corrotto o si stanno cercando di eseguire dei dati.
482 Quest'ultimo caso può accadere quando si passa un puntatore sbagliato al
483 posto di un puntatore a funzione, o si eccede la scrittura di un vettore di
484 una variabile locale, andando a corrompere lo stack. Lo stesso segnale viene
485 generato in caso di overflow dello stack o di problemi nell'esecuzione di un
486 manipolatore. Se il manipolatore ritorna il comportamento del processo è
488 \item[\macro{SIGSEGV}] Il nome deriva da \textit{segment violation}, e
489 significa che il programma sta cercando di leggere o scrivere in una zona di
490 memoria protetta al di fuori di quella che gli è stata riservata dal
491 sistema. In genere è il meccanismo della protezione della memoria che si
492 accorge dell'errore ed il kernel genera il segnale. Se il manipolatore
493 ritorna il comportamento del processo è indefinito.
495 È tipico ottenere questo segnale dereferenziando un puntatore nullo o non
496 inizializzato leggendo al di la della fine di un vettore.
497 \item[\macro{SIGBUS}] Il nome deriva da \textit{bus error}. Come
498 \macro{SIGSEGV} questo è un segnale che viene generato di solito quando si
499 dereferenzia un puntatore non inizializzato, la differenza è che
500 \macro{SIGSEGV} indica un accesso non permesso su un indirizzo esistente
501 (tipo fuori dallo heap o dallo stack), mentre \macro{SIGBUS} indica
502 l'accesso ad un indirizzo non valido, come nel caso di un puntatore non
504 \item[\macro{SIGABRT}] Il nome deriva da \textit{abort}. Il segnale indica che
505 il programma stesso ha rilevato un errore che viene riportato chiamando la
506 funzione \func{abort} che genera questo segnale.
507 \item[\macro{SIGTRAP}] È il segnale generato da un'istruzione di breakpoint o
508 dall'attivazione del tracciamento per il processo. È usato dai programmi per
509 il debugging e se un programma normale non dovrebbe ricevere questo segnale.
510 \item[\macro{SIGSYS}] Sta ad indicare che si è eseguita una istruzione che
511 richiede l'esecuzione di una system call, ma si è fornito un codice
512 sbagliato per quest'ultima.
516 \subsection{I segnali di terminazione}
517 \label{sec:sig_termination}
519 Questo tipo di segnali sono usati per terminare un processo; hanno vari nomi a
520 causa del differente uso che se ne può fare, ed i programmi possono
521 trattarli in maniera differente.
523 La ragione per cui può essere necessario trattare questi segnali è che il
524 programma può dover eseguire una serie di azioni di pulizia prima di
525 terminare, come salvare informazioni sullo stato in cui si trova, cancellare
526 file temporanei, o ripristinare delle condizioni alterate durante il
527 funzionamento (come il modo del terminale o i settaggi di una qualche
530 L'azione di default di questi segnali è di terminare il processo, questi
532 \begin{basedescript}{\desclabelwidth{2.0cm}}
533 \item[\macro{SIGTERM}] Il nome sta per \textit{terminate}. È un segnale
534 generico usato per causare la conclusione di un programma. Al contrario di
535 \macro{SIGKILL} può essere intercettato, ignorato, bloccato. In genere lo si
536 usa per chiedere in maniera ``educata'' ad un processo di concludersi.
537 \item[\macro{SIGINT}] Il nome sta per \textit{interrupt}. È il segnale di
538 interruzione per il programma. È quello che viene generato di default dal
539 comando \cmd{kill} o dall'invio sul terminale del carattere di controllo
540 INTR (interrupt, generato dalla sequenza \macro{C-c}).
541 \item[\macro{SIGQUIT}] È analogo a \macro{SIGINT} con la differenze che è
542 controllato da un'altro carattere di controllo, QUIT, corrispondente alla
543 sequenza \verb|C-\|. A differenza del precedente l'azione di default,
544 oltre alla terminazione del processo, comporta anche la creazione di un core
547 In genere lo si può pensare come corrispondente ad una condizione di
548 errore del programma rilevata dall'utente. Per questo motivo non è opportuno
549 fare eseguire al manipolatore di questo segnale le operazioni di pulizia
550 normalmente previste (tipo la cancellazione di file temporanei), dato che in
551 certi casi esse possono eliminare informazioni utili nell'esame dei core
553 \item[\macro{SIGKILL}] Il nome è utilizzato per terminare in maniera immediata
554 qualunque programma. Questo segnale non può essere né intercettato, né
555 ignorato, né bloccato, per cui causa comunque la terminazione del processo.
556 In genere esso viene generato solo per richiesta esplicita dell'utente dal
557 comando (o tramite la funzione) \cmd{kill}. Dato che non lo si può
558 intercettare è sempre meglio usarlo come ultima risorsa quando metodi meno
559 brutali, come \macro{SIGTERM} o \macro{C-c} non funzionano.
561 Se un processo non risponde a nessun altro segnale \macro{SIGKILL} ne causa
562 sempre la terminazione (in effetti il fallimento della terminazione di un
563 processo da parte di \macro{SIGKILL} costituirebbe un malfunzionamento del
564 kernel). Talvolta è il sistema stesso che può generare questo segnale quando
565 per condizioni particolari il processo non può più essere eseguito neanche
566 per eseguire un manipolatore.
567 \item[\macro{SIGHUP}] Il nome sta per \textit{hang-up}. Segnala che il
568 terminale dell'utente si è disconnesso (ad esempio perché si è interrotta la
569 rete). Viene usato anche per riportare la terminazione del processo di
570 controllo di un terminale a tutti i processi della sessione, in modo che
571 essi possano disconnettersi dal relativo terminale.
573 Viene inoltre usato in genere per segnalare ai demoni (che non hanno un
574 terminale di controllo) la necessità di reinizializzarsi e rileggere il/i
575 file di configurazione.
579 \subsection{I segnali di allarme}
580 \label{sec:sig_alarm}
582 Questi segnali sono generati dalla scadenza di un timer. Il loro comportamento
583 di default è quello di causare la terminazione del programma, ma con questi
584 segnali la scelta di default è irrilevante, in quanto il loro uso presuppone
585 sempre la necessità di un manipolatore. Questi segnali sono:
586 \begin{basedescript}{\desclabelwidth{2.0cm}}
587 \item[\macro{SIGALRM}] Il nome sta per \textit{alarm}. Segnale la scadenza di
588 un timer misurato sul tempo reale o sull'orologio di sistema. È normalmente
589 usato dalla funzione \func{alarm}.
590 \item[\macro{SIGVTALRM}] Il nome sta per \textit{virtual alarm}. È analogo al
591 precedente ma segnala la scadenza di un timer sul tempo di CPU usato dal
593 \item[\macro{SIGPROF}] Il nome sta per \textit{profiling}. Indica la scadenza
594 di un timer che misura sia il tempo di CPU speso direttamente dal processo
595 che quello che il sistema ha speso per conto di quest'ultimo. In genere
596 viene usato dai tool che servono a fare il profilo d'uso della CPU da parte
601 \subsection{I segnali di I/O asincrono}
602 \label{sec:sig_asyncio}
604 Questi segnali operano in congiunzione con le funzioni di I/O asincrono. Per
605 questo occorre comunque usare \func{fcntl} per abilitare un file descriptor a
606 generare questi segnali.
608 L'azione di default è di essere ignorati. Questi segnali sono:
609 \begin{basedescript}{\desclabelwidth{2.0cm}}
610 \item[\macro{SIGIO}] Questo segnale viene inviato quando un file descriptor è
611 pronto per eseguire dell'input/output. In molti sistemi solo i socket e i
612 terminali possono generare questo segnale, in Linux questo può essere usato
613 anche per i file, posto che la \func{fcntl} abbia avuto successo.
614 \item[\macro{SIGURG}] Questo segnale è inviato quando arrivano dei dati
615 urgenti o \textit{out of band} su di un socket; per maggiori dettagli al
616 proposito si veda \secref{sec:xxx_urgent_data}.
617 \item[\macro{SIGPOLL}] Questo segnale è equivalente a \macro{SIGIO}, è
618 definito solo per compatibilità con i sistemi System V.
622 \subsection{I segnali per il controllo di sessione}
623 \label{sec:sig_job_control}
625 Questi sono i segnali usati dal controllo delle sessioni e dei processi, il
626 loro uso è specifico e viene trattato in maniera specifica nelle sezioni in
627 cui si trattano gli argomenti relativi. Questi segnali sono:
628 \begin{basedescript}{\desclabelwidth{2.0cm}}
629 \item[\macro{SIGCHLD}] Questo è il segnale mandato al processo padre quando un
630 figlio termina o viene fermato. L'azione di default è di ignorare il
631 segnale, la sua gestione è trattata in \secref{sec:proc_wait}.
632 \item[\macro{SIGCLD}] Per Linux questo è solo un segnale identico al
633 precedente, il nome è obsoleto e andrebbe evitato.
634 \item[\macro{SIGCONT}] Il nome sta per \textit{continue}. Il segnale viene
635 usato per fare ripartire un programma precedentemente fermato da
636 \macro{SIGSTOP}. Questo segnale ha un comportamento speciale, e fa sempre
637 ripartire il processo prima della sua consegna. Il comportamento di default
638 è di fare solo questo; il segnale non può essere bloccato. Si può anche
639 installare un manipolatore, ma il segnale provoca comunque il riavvio del
642 La maggior pare dei programmi non hanno necessità di intercettare il
643 segnale, in quanto esso è completamente trasparente rispetto all'esecuzione
644 che riparte senza che il programma noti niente. Si possono installare dei
645 manipolatori per far si che un programma produca una qualche azione speciale
646 se viene fermato e riavviato, come per esempio riscrivere un prompt, o
648 \item[\macro{SIGSTOP}] Il segnale ferma un processo (lo porta in uno stato di
649 sleep); il segnale non può essere né intercettato, né ignorato, né bloccato.
650 \item[\macro{SIGTSTP}] Il nome sta per \textit{interactive stop}. Il segnale
651 ferma il processo interattivamente, ed è generato dal carattere SUSP
652 (prodotto dalla combinazione \macro{C-z}), ed al contrario di
653 \macro{SIGSTOP} può essere intercettato e ignorato. In genere un programma
654 installa un manipolatore per questo segnale quando vuole lasciare il sistema
655 o il terminale in uno stato definito prima di fermarsi; se per esempio un
656 programma ha disabilitato l'eco sul terminale può installare un manipolatore
657 per riabilitarlo prima di fermarsi.
658 \item[\macro{SIGTTIN}] Un processo non può leggere dal terminale se esegue una
659 sessione di lavoro in background. Quando un processo in background tenta di
660 leggere da un terminale viene inviato questo segnale a tutti i processi
661 della sessione di lavoro. L'azione di default è di fermare il processo.
662 L'argomento è trattato in \secref{sec:sess_xxx}.
663 \item[\macro{SIGTTOU}] Segnale analogo al precedente \macro{SIGTTIN}, ma
664 generato quando si tenta di scrivere o modificare uno dei modi del
665 terminale. L'azione di default è di fermare il processo, l'argomento è
666 trattato in \secref{sec:sess_xxx}.
670 \subsection{I segnali di operazioni errate}
671 \label{sec:sig_oper_error}
673 Questi segnali sono usati per riportare al programma errori generati da
674 operazioni da lui eseguite; non indicano errori del programma quanto errori
675 che impediscono il completamento dell'esecuzione dovute all'interazione con il
678 L'azione di default di questi segnali è di terminare il processo, questi
680 \begin{basedescript}{\desclabelwidth{2.0cm}}
681 \item[\macro{SIGPIPE}] Sta per \textit{Broken pipe}. Se si usano delle pipe o
682 delle FIFO è necessario che, prima che un processo inizi a scrivere su di
683 essa, un'altro abbia aperto la pipe in lettura (si veda
684 \secref{sec:ipc_pipes}). Se il processo in lettura non è partito o è
685 terminato inavvertitamente alla scrittura sulla pipe il kernel genera questo
686 segnale. Se il segnale è bloccato, intercettato o ignorato la chiamata che
687 lo ha causato fallisce restituendo l'errore \macro{EPIPE}
688 \item[\macro{SIGLOST}] Sta per \textit{Resource lost}. Viene generato quando
689 c'è un advisory lock su un file NFS, ed il server riparte dimenticando la
690 situazione precedente.
691 \item[\macro{SIGXCPU}] Sta per \textit{CPU time limit exceeded}. Questo
692 segnale è generato quando un processo eccede il limite impostato per il
693 tempo di CPU disponibile, vedi \secref{sec:sys_xxx}.
694 \item[\macro{SIGXFSZ}] Sta per \textit{File size limit exceeded}. Questo
695 segnale è generato quando un processo tenta di estendere un file oltre le
696 dimensioni specificate dal limite impostato per le dimensioni massime di un
697 file, vedi \secref{sec:sys_xxx}.
701 \subsection{Ulteriori segnali}
702 \label{sec:sig_misc_sig}
704 Raccogliamo qui infine usa serie di segnali che hanno scopi differenti non
705 classificabili in maniera omogenea. Questi segnali sono:
706 \begin{basedescript}{\desclabelwidth{2.0cm}}
707 \item[\macro{SIGUSR1} e \macro{SIGUSR2}] Sono due segnali a disposizione
708 dell'utente che li può usare per quello che vuole. Possono essere utili per
709 implementare una comunicazione elementare fra processi diversi, o per
710 eseguire a richiesta una operazione utilizzando un manipolatore. L'azione di
711 default è terminare il processo.
712 \item[\macro{SIGWINCH}] Il nome sta per \textit{window (size) change} ed è
713 generato da 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 di default è di essere ignorato.
717 \item[\macro{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.
724 \subsection{Le funzioni \func{strsignal} e \func{psignal}}
725 \label{sec:sig_strsignal}
727 Per la descrizione dei segnali il sistema mette a disposizione due funzioni,
728 \func{strsignal} e \func{psignal}, che stampano un messaggio di descrizione
729 dato il numero. In genere si usano quando si vuole notificare all'utente il
730 segnale avvenuto (nel caso di terminazione di un processo figlio o di un
731 manipolatore che gestisce più segnali); la prima funzione è una estensione
732 GNU, accessibile avendo definito \macro{\_GNU\_SOURCE}, ed è analoga alla
733 funzione \func{strerror} (si veda \secref{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
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à
743 La seconda funzione deriva da BSD ed è analoga alla funzione \func{perror}
744 descritta in \secref{sec:sys_strerror}; il suo prototipo è:
745 \begin{prototype}{signal.h}{void psignal(int sig, const char *s)}
746 Stampa sullo standard error un messaggio costituito dalla stringa \param{s},
747 seguita da due punti ed una descrizione del segnale indicato da \param{sig}.
750 Una modalità alternativa per utilizzare le descrizioni restituite da
751 \func{strsignal} e \func{psignal} è quello di fare usare la variabile
752 \var{sys\_siglist}, che è definita in \file{signal.h} e può essere acceduta
753 con la dichiarazione:
754 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
755 extern const char *const sys_siglist[]
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]}.
764 \section{La gestione dei segnali}
765 \label{sec:sig_management}
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 manipolatori che si sono installati.
773 In questa sezione vedremo come si effettua gestione dei segnali, a partire
774 dalla loro interazione con le system call, passando per le varie funzioni che
775 permettono di installare i manipolatori e controllare le reazioni di un
776 processo alla loro occorrenza.
779 \subsection{Il comportamento generale del sistema.}
780 \label{sec:sig_gen_beha}
782 Abbiamo già trattato in \secref{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.
788 Come accennato in \secref{sec:proc_fork} quando viene creato un nuovo processo
789 con \func{fork} esso eredita dal padre sia le azioni che sono state settate
790 per i singoli segnali, che la maschera dei segnali bloccati (tratteremo
791 quest'ultimo argomento in \ref{sec:sig_sigpending}). Invece tutti i segnali
792 pendenti e gli allarmi vengono cancellati; essi infatti devono essere
793 recapitati solo al padre, al figlio dovranno arrivare solo i segnali dovuti
796 Quando si mette in esecuzione un nuovo programma con \func{exec} (si ricordi
797 quanto detto in \secref{sec:proc_exec}) tutti i segnali per i quali è stato
798 installato un manipolatore vengono resettati a \macro{SIG\_DFL}. Non ha più
799 senso infatti fare riferimento a funzioni definite nel programma originario,
800 che non sono presenti nello spazio di indirizzi del nuovo programma.
802 Si noti che questo vale solo per le azioni per le quali è stato installato un
803 manipolatore; viene mantenuto invece ogni eventuale settaggio dell'azione a
804 \macro{SIG\_IGN}. Questo permette ad esempio alla shell di settare ad
805 \macro{SIG\_IGN} le risposte per \macro{SIGINT} e \macro{SIGQUIT} per i
806 programmi eseguiti in background, che altrimenti sarebbero interrotti da una
807 successiva pressione di \texttt{C-c} o \texttt{C-y}.
809 Per quanto riguarda tutte le altre system call esse vengono tradizionalmente
810 classificate, proprio in base al loro comportamento nei confronti dei segnali,
811 in \textsl{lente} (\textit{slow}) e \textsl{veloci} (\textit{fast}). La gran
812 parte appartiene a quest'ultima categoria che non è influenzata dall'arrivo di
813 un segnale. In tal caso un eventuale manipolatore viene sempre eseguito dopo
814 che la system call è stata completata. Esse sono dette \textsl{veloci} proprio
815 in quanto la loro esecuzione è sostanzialmente immediata e attendere per
816 eseguire un manipolatore non comporta nessun inconveniente.
818 Esistono però dei casi in cui questo non è possibile perché renderebbe
819 impossibile una risposta pronta al segnale. In generale questo avviene tutte
820 le volte che si ha a che fare con system call che possono bloccarsi
821 indefinitamente, (quelle che, per questo, vengono chiamate \textsl{lente}). Un
822 elenco dei casi in cui si presenta questa situazione è il seguente:
824 \item lettura da file che possono bloccarsi in attesa di dati non ancora
825 presenti (come per certi file di dispositivo, la rete o le pipe).
826 \item scrittura sugli stessi file, nel caso in cui dati non possano essere
827 accettati immediatamente.
828 \item apertura di un file di dispositivo che richiede operazioni non immediate
829 per una una risposta.
830 \item operazioni eseguite con \func{ioctl} che non è detto possano essere
831 eseguite immediatamente.
832 \item le funzioni di intercomunicazione che si bloccano in attesa di risposte
834 \item la funzione \func{pause} (usata appunto per attendere l'-arrivo di un
836 \item la funzione \func{wait} (se nessun processo figlio è ancora terminato).
839 In questo caso si pone il problema di cosa fare una volta che il manipolatore
840 sia ritornato. La scelta originaria dei primi Unix era quella di far ritornare
841 anche la system call restituendo l'errore di \macro{EINTR}. Questa è a
842 tutt'oggi una scelta corrente, ma comporta che i programmi che usano dei
843 manipolatori controllino lo stato di uscita delle funzioni per ripeterne la
844 chiamata qualora l'errore fosse questo.
846 Dimenticarsi di richiamare una system call interrotta da un segnale è un
847 errore comune, tanto che le \acr{glibc} provvedono una macro
848 \code{TEMP\_FAILURE\_RETRY(expr)} che esegue l'operazione automaticamente,
849 ripetendo l'esecuzione dell'espressione \var{expr} fintanto che il risultato
850 non è diverso dall'uscita con un errore \macro{EINTR}.
852 La soluzione è comunque poco elegante e BSD ha scelto un approccio molto
853 diverso, che è quello di fare ripartire automaticamente la system call invece
854 di farla fallire. In questo caso ovviamente non c'è da preoccuparsi di
855 controllare il codice di errore; si perde però la possibilità di eseguire
856 azioni specifiche all'occorrenza di questa particolare condizione.
858 Linux e le \acr{glibc} consentono di utilizzare entrambi gli approcci,
859 attraverso una opportuna opzione di \func{sigaction} (vedi
860 \secref{sec:sig_sigaction}). È da chiarire comunque che nel caso di
861 interruzione nel mezzo di un trasferimento parziale di dati, le system call
862 ritornano sempre indicando i byte trasferiti.
865 \subsection{La funzione \func{signal}}
866 \label{sec:sig_signal}
868 L'interfaccia più semplice per la gestione dei segnali è costituita dalla
869 funzione \func{signal} che è definita fin dallo standard ANSI C. Quest'ultimo
870 però non considera sistemi multitasking, per cui la definizione è tanto vaga
871 da essere del tutto inutile in un sistema Unix; è questo il motivo per cui
872 ogni implementazione successiva ne ha modificato e ridefinito il
873 comportamento, pur mantenendone immutato il prototipo\footnote{in realtà
874 alcune vecchie implementazioni (SVR4 e 4.3+BSD) usano parametri aggiuntivi
875 per definire il comportamento della funzione.} che è:
876 \begin{prototype}{signal.h}
877 {sighandler\_t signal(int signum, sighandler\_t handler)}
879 Installa la funzione di gestione \param{handler} (il manipolatore) per il
880 segnale \param{signum}.
882 \bodydesc{La funzione ritorna il precedente manipolatore in caso di successo
883 o \macro{SIG\_ERR} in caso di errore.}
886 In questa definizione si è usato il tipo \type{sighandler\_t} che è una
887 estensione GNU, definita dalle \acr{glibc}, che permette di riscrivere il
888 prototipo in una forma più leggibile dell'originario:
890 void (*signal(int signum, void (*handler)(int)))int)
892 questa infatti, per la poca chiarezza della sintassi del C quando si vanno a
893 trattare puntatori a funzioni, è molto meno comprensibile. Da un confronto
894 con il precedente prototipo si può dedurre la definizione di
895 \type{sighandler\_t} che è:
897 typedef void (* sighandler_t)(int)
899 e cioè un puntatore ad una funzione \ctyp{void} (cioè senza valore di ritorno)
900 e che prende un argomento di tipo \ctyp{int}.\footnote{si devono usare le
901 parentesi intorno al nome della funzione per via delle precedenze degli
902 operatori del C, senza di esse si sarebbe definita una funzione che ritorna
903 un puntatore a \ctyp{void} e non un puntatore ad una funzione \ctyp{void}.}
904 La funzione \func{signal} quindi restituisce e prende come secondo argomento
905 un puntatore a una funzione di questo tipo, che è appunto il manipolatore del
908 Il numero di segnale passato in \param{signum} può essere indicato
909 direttamente con una delle costanti definite in \secref{sec:sig_standard}. Il
910 manipolatore \param{handler} invece, oltre all'indirizzo della funzione da
911 chiamare all'occorrenza del segnale, può assumere anche i due valori costanti
912 \macro{SIG\_IGN} con cui si dice ignorare il segnale e \macro{SIG\_DFL} per
913 installare l'azione di di default.\footnote{si ricordi però che i due segnali
914 \macro{SIGKILL} e \macro{SIGSTOP} non possono essere ignorati né
917 La funzione restituisce l'indirizzo dell'azione precedente, che può essere
918 salvato per poterlo ripristinare (con un'altra chiamata a \func{signal}) in un
919 secondo tempo. Si ricordi che se si setta come azione \macro{SIG\_IGN} (o si
920 setta un \macro{SIG\_DFL} per un segnale il cui default è di essere ignorato),
921 tutti i segnali pendenti saranno scartati, e non verranno mai notificati.
923 L'uso di \func{signal} è soggetto a problemi di compatibilità, dato che essa
924 si comporta in maniera diversa per sistemi derivati da BSD o da System V. In
925 questi ultimi infatti la funzione è conforme al comportamento originale dei
926 primi Unix in cui il manipolatore viene disinstallato alla sua chiamata,
927 secondo la semantica inaffidabile; Linux seguiva questa convenzione fino alle
928 \acr{libc5}. Al contrario BSD segue la semantica affidabile, non resettando il
929 manipolatore e bloccando il segnale durante l'esecuzione dello stesso. Con
930 l'utilizzo delle \acr{glibc2} anche Linux è passato a questo comportamento;
931 quello della versione originale della funzione, il cui uso è deprecato per i
932 motivi visti in \secref{sec:sig_semantics}, può essere ottenuto chiamando
933 \func{sysv\_signal}. In generale, per evitare questi problemi, tutti i nuovi
934 programmi dovrebbero usare \func{sigaction}.
936 È da tenere presente che, seguendo lo standard POSIX, il comportamento di un
937 processo che ignora i segnali \macro{SIGFPE}, \macro{SIGILL}, o
938 \macro{SIGSEGV} (qualora non originino da una \func{kill} o una \func{raise})
939 è indefinito. Un manipolatore che ritorna da questi segnali può dare luogo ad
943 \subsection{Le funzioni \func{kill} e \func{raise}}
944 \label{sec:sig_kill_raise}
946 Come accennato in \secref{sec:sig_types}, un segnale può essere generato
947 direttamente da un processo. L'invio di un segnale generico può essere
948 effettuato attraverso delle funzioni \func{kill} e \func{raise}. La prima
949 serve per inviare un segnale al processo corrente, ed il suo prototipo è:
950 \begin{prototype}{signal.h}{int raise(int sig)}
951 Invia il segnale \param{sig} al processo corrente.
953 \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
954 errore, il solo errore restituito è \macro{EINVAL} qualora si sia
955 specificato un numero di segnale invalido.}
958 Il valore di \param{sig} specifica il segnale che si vuole inviare e può
959 essere specificato con una delle macro definite in
960 \secref{sec:sig_classification}. In genere questa funzione viene usata per
961 riprodurre il comportamento di default di un segnale che sia stato
962 intercettato. In questo caso, una volta eseguite le operazioni volute, il
963 manipolatore potrà reinstallare l'azione di default, e attivarla con
966 Se invece si vuole inviare un segnale ad un altro processo occorre utilizzare
967 la funzione \func{kill}; il cui prototipo è:
969 \headdecl{sys/types.h}
971 \funcdecl{int kill(pid\_t pid, int sig)} Invia il segnale \param{sig} al
972 processo specificato con \param{pid}.
974 \bodydesc{ La funzione restituisce 0 in caso di successo e -1 in caso di
975 errore nel qual caso \var{errno} può assumere i valori:
977 \item[\macro{EINVAL}] Il segnale specificato non esiste.
978 \item[\macro{ESRCH}] Il processo selezionato non esiste.
979 \item[\macro{EPERM}] Non si hanno privilegi sufficienti ad inviare il
984 Lo standard POSIX prevede che il valore 0 per \param{sig} sia usato per
985 specificare il segnale nullo. Se le funzioni vengono chiamate con questo
986 valore non viene inviato nessun segnale, ma viene eseguito il controllo degli
987 errori, in tal caso si otterrà un errore \macro{EPERM} se non si hanno i
988 permessi necessari ed un errore \macro{ESRCH} se il processo specificato non
989 esiste. Si tenga conto però che il sistema ricicla i \acr{pid} (come accennato
990 in \secref{sec:proc_pid}) per cui l'esistenza di un processo non significa che
991 esso sia realmente quello a cui si intendeva mandare il segnale.
993 Il valore dell'argomento \param{pid} specifica il processo (o i processi) di
994 destinazione a cui il segnale deve essere inviato e può assumere i valori
995 riportati in \tabref{tab:sig_kill_values}.
999 \begin{tabular}[c]{|r|l|}
1001 \textbf{Valore} & \textbf{Significato} \\
1004 $>0$ & il segnale è mandato al processo con il \acr{pid} indicato.\\
1005 0 & il segnale è mandato ad ogni processo del \textit{process group}
1007 $-1$ & il segnale è mandato ad ogni processo (eccetto \cmd{init}).\\
1008 $<-1$ & il segnale è mandato ad ogni processo del process group
1012 \caption{Valori dell'argomento \param{pid} per la funzione
1014 \label{tab:sig_kill_values}
1017 Si noti pertanto che la funzione \code{raise(sig)} può essere definita in
1018 termini di \func{kill}, ed è sostanzialmente equivalente ad una
1019 \code{kill(getpid(), sig)}. Siccome \func{raise}, che è definita nello
1020 standard ISO C, non esiste in alcune vecchie versioni di Unix, in generale
1021 l'uso di \func{kill} finisce per essere più portabile.
1023 Solo l'amministratore può inviare un segnale ad un processo qualunque, in
1024 tutti gli altri casi il \textit{real user id} o l'\textit{effective user id}
1025 del processo chiamante devono corrispondere al \textit{real user id} o al
1026 \textit{saved user id} della destinazione. Fa eccezione il caso in cui il
1027 segnale inviato sia \macro{SIGCONT}, nel quale occorre che entrambi i processi
1028 appartengano alla stessa sessione. Inoltre, dato il ruolo fondamentale che
1029 riveste nel sistema (si ricordi quanto visto in \secref{sec:sig_termination}),
1030 non è possibile inviare al processo 1 (cioè a \cmd{init}) segnali per i quali
1031 esso non abbia un manipolatore installato.
1033 Infine, seguendo le specifiche POSIX 1003.1-2001, l'uso della chiamata
1034 \code{kill(-1, sig)} comporta che il segnale sia inviato (con la solita
1035 eccezione di \cmd{init}) a tutti i processi per i quali i permessi lo
1036 consentano. Lo standard permette comunque alle varie implementazione di
1037 escludere alcuni processi specifici: nel caso in questione Linux non invia il
1038 segnale al processo che ha effettuato la chiamata.
1041 \subsection{Le funzioni \func{alarm} e \func{abort}}
1042 \label{sec:sig_alarm_abort}
1044 Un caso particolare di segnali generati a richiesta è quello che riguarda i
1045 vari segnali di temporizzazione e \macro{SIGABORT}, per ciascuno di questi
1046 segnali sono previste funzioni specifiche che ne effettuino l'invio. La più
1047 comune delle funzioni usate per la temporizzazione è \func{alarm} il cui
1049 \begin{prototype}{unistd.h}{unsigned int alarm(unsigned int seconds)}
1050 Predispone l'invio di \macro{SIGALARM} dopo \param{seconds} secondi.
1052 \bodydesc{La funzione restituisce il numero di secondi rimanenti ad un
1053 precedente allarme, o zero se non c'erano allarmi pendenti.}
1056 La funzione fornisce un meccanismo che consente ad un processo di predisporre
1057 un'interruzione nel futuro, (ad esempio per effettuare una qualche operazione
1058 dopo un certo periodo di tempo), programmando l'emissione di un segnale (nel
1059 caso in questione \macro{SIGALARM}) dopo il numero di secondi specificato da
1062 Se si specifica per \param{seconds} un valore nullo non verrà inviato nessun
1063 segnale; siccome alla chiamata viene cancellato ogni precedente allarme,
1064 questo può essere usato per cancellare una programmazione precedente.
1066 La funzione inoltre ritorna il numero di secondi rimanenti all'invio
1067 dell'allarme precedentemente programmato, in modo che sia possibile
1068 controllare se non si cancella un precedente allarme ed eventualmente
1069 predisporre le opportune misure per gestire il caso di necessità di più
1072 In \secref{sec:sys_unix_time} abbiamo visto che ad ogni processo sono
1073 associati tre tempi diversi: il \textit{clock time}, l'\textit{user time} ed
1074 il \textit{system time}. Per poterli calcolare il kernel mantiene per ciascun
1075 processo tre diversi timer:
1077 \item un \textit{real-time timer} che calcola il tempo reale trascorso (che
1078 corrisponde al \textit{clock time}). La scadenza di questo timer provoca
1079 l'emissione di \macro{SIGALARM}.
1080 \item un \textit{virtual timer} che calcola il tempo di processore usato dal
1081 processo in user space (che corrisponde all'\textit{user time}). La scadenza
1082 di questo timer provoca l'emissione di \macro{SIGVTALRM}.
1083 \item un \textit{profiling timer} che calcola la somma dei tempi di processore
1084 utilizzati direttamente dal processo in user space, e dal kernel nelle
1085 system call ad esso relative (che corrisponde a quello che in
1086 \secref{sec:sys_unix_time} abbiamo chiamato \textit{CPU time}). La scadenza
1087 di questo timer provoca l'emissione di \macro{SIGPROF}.
1090 Il timer usato da \func{alarm} è il \textit{clock time}, e corrisponde cioè al
1091 tempo reale. La funzione come abbiamo visto è molto semplice, ma proprio per
1092 questo presenta numerosi limiti: non consente di usare gli altri timer, non
1093 può specificare intervalli di tempo con precisione maggiore del secondo e
1094 genera il segnale una sola volta.
1096 Per ovviare a questi limiti Linux deriva da BSD la funzione \func{setitimer}
1097 che permette di usare un timer qualunque e l'invio di segnali periodici, al
1098 costo però di una maggiore complessità d'uso e di una minore portabilità. Il
1100 \begin{prototype}{sys/time.h}{int setitimer(int which, const struct
1101 itimerval *value, struct itimerval *ovalue)}
1103 Predispone l'invio di un segnale di allarme alla scadenza dell'intervallo
1104 \param{value} sul timer specificato da \func{which}.
1106 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1107 errore, nel qual caso \var{errno} può assumere i valori \macro{EINVAL} e
1111 Il valore di \param{which} permette di specificare quale dei tre timer
1112 illustrati in precedenza usare; i possibili valori sono riportati in
1113 \tabref{tab:sig_setitimer_values}.
1117 \begin{tabular}[c]{|l|l|}
1119 \textbf{Valore} & \textbf{Timer} \\
1122 \macro{ITIMER\_REAL} & \textit{real-time timer}\\
1123 \macro{ITIMER\_VIRTUAL} & \textit{virtual timer}\\
1124 \macro{ITIMER\_PROF} & \textit{profiling timer}\\
1127 \caption{Valori dell'argomento \param{which} per la funzione
1129 \label{tab:sig_setitimer_values}
1132 Il valore della struttura specificata \param{value} viene usato per settare il
1133 timer, se il puntatore \param{ovalue} non è nullo il precedente valore viene
1134 salvato qui. I valori dei timer devono essere indicati attraverso una
1135 struttura \var{itimerval}, definita in \figref{fig:file_stat_struct}.
1137 La struttura è composta da due membri, il primo, \var{it\_interval} definisce
1138 il periodo del timer; il secondo, \var{it\_value} il tempo mancante alla
1139 scadenza. Entrambi esprimono i tempi tramite una struttura \var{timeval} che
1140 permette una precisione fino al microsecondo.
1142 Ciascun timer decrementa il valore di \var{it\_value} fino a zero, poi invia
1143 il segnale e resetta \var{it\_value} al valore di \var{it\_interval}, in
1144 questo modo il ciclo verrà ripetuto; se invece il valore di \var{it\_interval}
1145 è nullo il timer si ferma.
1147 \begin{figure}[!htb]
1148 \footnotesize \centering
1149 \begin{minipage}[c]{15cm}
1150 \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
1153 struct timeval it_interval; /* next value */
1154 struct timeval it_value; /* current value */
1159 long tv_sec; /* seconds */
1160 long tv_usec; /* microseconds */
1165 \caption{La struttura \var{itimerval}, che definisce i valori dei timer di
1167 \label{fig:sig_itimerval}
1170 L'uso di \func{setitimer} consente dunque un controllo completo di tutte le
1171 caratteristiche dei timer, ed in effetti la stessa \func{alarm}, benché
1172 definita direttamente nello standard POSIX.1, può a sua volta essere espressa
1173 in termini di \func{setitimer}, come evidenziato dal manuale delle \acr{glibc}
1174 \cite{glibc} che ne riporta la definizione mostrata in
1175 \figref{fig:sig_alarm_def}.
1177 \begin{figure}[!htb]
1178 \footnotesize \centering
1179 \begin{minipage}[c]{15cm}
1180 \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
1181 unsigned int alarm(unsigned int seconds)
1183 struct itimerval old, new;
1184 new.it_interval.tv_usec = 0;
1185 new.it_interval.tv_sec = 0;
1186 new.it_value.tv_usec = 0;
1187 new.it_value.tv_sec = (long int) seconds;
1188 if (setitimer(ITIMER_REAL, &new, &old) < 0) {
1192 return old.it_value.tv_sec;
1198 \caption{Definizione di \func{alarm} in termini di \func{setitimer}.}
1199 \label{fig:sig_alarm_def}
1202 Si deve comunque tenere presente che la precisione di queste funzioni è
1203 limitata da quella della frequenza del timer di sistema (che nel caso dei PC
1204 significa circa 10~ms). Il sistema assicura comunque che il segnale non sarà
1205 mai generato prima della scadenza programmata (l'arrotondamento cioè è sempre
1206 effettuato per eccesso).
1208 Una seconda causa di potenziali ritardi è che il segnale viene generato alla
1209 scadenza del timer, ma poi deve essere consegnato al processo; se quest'ultimo
1210 è attivo (questo è sempre vero per \macro{ITIMER\_VIRT}) la consegna è
1211 immediata, altrimenti può esserci un ulteriore ritardo che può variare a
1212 seconda del carico del sistema.
1214 Questo ha una conseguenza che può indurre ad errori molto subdoli, si tenga
1215 conto poi che in caso di sistema molto carico, si può avere il caso patologico
1216 in cui un timer scade prima che il segnale di una precedente scadenza sia
1217 stato consegnato; in questo caso, per il comportamento dei segnali descritto
1218 in \secref{sec:sig_sigchld}, un solo segnale sarà consegnato.
1221 Dato che sia \func{alarm} che \func{setitimer} non consentono di leggere il
1222 valore corrente di un timer senza modificarlo, è possibile usare la funzione
1223 \func{getitimer}, il cui prototipo è:
1224 \begin{prototype}{sys/time.h}{int getitimer(int which, struct
1227 Legge in \param{value} il valore del timer specificato da \func{which}.
1229 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1230 errore e restituisce gli stessi errori di \func{getitimer}}
1232 \noindent i cui parametri hanno lo stesso significato e formato di quelli di
1236 L'ultima funzione che permette l'invio diretto di un segnale è \func{abort};
1237 che, come accennato in \ref{sec:proc_termination}, permette di abortire
1238 l'esecuzione di un programma tramite l'invio di \macro{SIGABRT}. Il suo
1240 \begin{prototype}{stdlib.h}{void abort(void)}
1242 Abortisce il processo corrente.
1244 \bodydesc{La funzione non ritorna, il processo è terminato inviando il
1245 segnale di \macro{SIGABRT}.}
1248 La differenza fra questa funzione e l'uso di \func{raise} è che anche se il
1249 segnale è bloccato o ignorato, la funzione ha effetto lo stesso. Il segnale
1250 può però essere intercettato per effettuare eventuali operazioni di chiusura
1251 prima della terminazione del processo.
1253 Lo standard ANSI C richiede inoltre che anche se il manipolatore ritorna, la
1254 funzione non ritorni comunque. Lo standard POSIX.1 va oltre e richiede che se
1255 il processo non viene terminato direttamente dal manipolatore sia la stessa
1256 \func{abort} a farlo al ritorno dello stesso. Inoltre, sempre seguendo lo
1257 standard POSIX, prima della terminazione tutti i file aperti e gli stream
1258 saranno chiusi ed i buffer scaricati su disco. Non verranno invece eseguite le
1259 eventuali funzioni registrate con \func{at\_exit} e \func{on\_exit}.
1262 \subsection{Le funzioni \func{pause} e \func{sleep}}
1263 \label{sec:sig_pause_sleep}
1265 Il metodo tradizionale per fare attendere\footnote{cioè di porre
1266 temporanemente il processo in stato di \textit{sleep}, vedi
1267 \ref{sec:proc_sched}.} ad un processo fino all'arrivo di un segnale è
1268 quello di usare la funzione \func{pause}, il cui prototipo è:
1269 \begin{prototype}{unistd.h}{int pause(void)}
1271 Pone il processo in stato di sleep fino al ritorno di un manipolatore.
1273 \bodydesc{La funzione ritorna solo dopo che un segnale è stato ricevuto ed
1274 il relativo manipolatore è ritornato, nel qual caso restituisce -1 e setta
1275 \var{errno} a \macro{EINTR}.}
1278 La funzione segnala sempre una condizione di errore (il successo sarebbe
1279 quello di aspettare indefinitamente). In genere si usa questa funzione quando
1280 si vuole mettere un processo in attesa di un qualche evento specifico che non
1281 è sotto il suo diretto controllo (ad esempio la si può usare per far reagire
1282 il processo ad un segnale inviato da un altro processo).
1284 Se invece si vuole fare attendere un processo per un determinato intervallo di
1285 tempo nello standard POSIX.1 viene definita la funzione \func{sleep}, il cui
1287 \begin{prototype}{unistd.h}{unsigned int sleep(unsigned int seconds)}
1289 Pone il processo in stato di sleep per \param{seconds} secondi.
1291 \bodydesc{La funzione restituisce zero se l'attesa viene completata, o il
1292 numero di secondi restanti se viene interrotta da un segnale.}
1295 La funzione attende per il tempo specificato, a meno di non essere interrotta
1296 da un segnale. In questo caso non è una buona idea ripetere la chiamata per il
1297 tempo rimanente, in quanto la riattivazione del processo può avvenire in un
1298 qualunque momento, ma il valore restituito sarà sempre arrotondato al secondo,
1299 con la conseguenza che, se la successione dei segnali è particolarmente
1300 sfortunata e le differenze si accumulano, si potranno avere ritardi anche di
1301 parecchi secondi. In genere la scelta più sicura è quella di stabilire un
1302 termine per l'attesa, e ricalcolare tutte le volte il numero di secondi da
1305 In alcune implementazioni inoltre l'uso di \func{sleep} può avere conflitti
1306 con quello di \macro{SIGALRM}, dato che la funzione può essere realizzata con
1307 l'uso di \func{pause} e \func{alarm} (in maniera analoga all'esempio che
1308 vedremo in \secref{sec:sig_example}). In tal caso mescolare chiamata di
1309 \func{alarm} e \func{sleep} o modificare l'azione di \macro{SIGALRM}, può
1310 causare risultati indefiniti. Nel caso delle \acr{glibc} è stata usata una
1311 implementazione completamente indipendente e questi problemi non ci sono.
1313 La granularità di \func{sleep} permette di specificare attese in secondi, per
1314 questo sia sotto BSD4.3 che in SUSv2 è stata definita la funzione
1315 \func{usleep} (dove la \texttt{u} è intesa come sostituzione di $\mu$); i due
1316 standard hanno delle definizioni diverse, ma le \acr{glibc}
1317 seguono\footnote{secondo la man page almeno dalla versione 2.2.2.} seguono
1318 quella di SUSv2 che prevede il seguente prototipo:
1319 \begin{prototype}{unistd.h}{int usleep(unsigned long usec)}
1321 Pone il processo in stato di sleep per \param{usec} microsecondi.
1323 \bodydesc{La funzione restituisce zero se l'attesa viene completata, o -1 in
1324 caso di errore, nel qual caso \var{errno} è settata a \macro{EINTR}.}
1328 Anche questa funzione, a seconda delle implementazioni, può presentare
1329 problemi nell'interazione con \func{alarm} e \macro{SIGALRM}. È pertanto
1330 deprecata in favore della funzione \func{nanosleep}, definita dallo standard
1331 POSIX1.b, il cui prototipo è:
1332 \begin{prototype}{unistd.h}{int nanosleep(const struct timespec *req, struct
1335 Pone il processo in stato di sleep per il tempo specificato da \param{req}.
1336 In caso di interruzione restituisce il tempo restante in \param{rem}.
1338 \bodydesc{La funzione restituisce zero se l'attesa viene completata, o -1 in
1339 caso di errore, nel qual caso \var{errno} è settata a
1341 \item[\macro{EINVAL}] si è specificato un numero di secondi negativo o un
1342 numero di nanosecondi maggiore di 999.999.999.
1343 \item[\macro{EINTR}] la funzione è stata interrotta da un segnale.
1347 Lo standard richiede che la funzione sia implementata in maniera del tutto
1348 indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto
1349 utilizzando direttamente il timer del kernel.} e sia utilizzabile senza
1350 interferenze con l'uso di \macro{SIGALRM}. La funzione prende come parametri
1351 delle strutture di tipo \var{timespec}, la cui definizione è riportata in
1352 \figref{fig:sig_timespec_def}, che permettono di specificare un tempo con una
1353 precisione (teorica) fino al nanosecondo.
1355 La funzione risolve anche il problema di proseguire l'attesa dopo
1356 l'interruzione dovuta ad un segnale; infatti in tal caso in \param{rem} viene
1357 restituito il tempo rimanente rispetto a quanto richiesto inizialmente, e
1358 basta richiamare la funzione per completare l'attesa.
1360 Chiaramente, anche se il tempo può essere specificato con risoluzioni fino al
1361 nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
1362 temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
1363 specificato, ma prima che il processo possa tornare ad essere eseguito
1364 occorrerà almeno attendere il successivo giro di scheduler e cioè un tempo che
1365 a seconda dei casi può arrivare fino a 1/\macro{HZ}, (sempre che il sistema
1366 sia scarico ed il processa venga immediatamente rimesso in esecuzione); per
1367 questo motivo il valore restituito in \param{rem} è sempre arrotondato al
1368 multiplo successivo di 1/\macro{HZ}.
1370 \begin{figure}[!htb]
1371 \footnotesize \centering
1372 \begin{minipage}[c]{15cm}
1373 \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
1375 time_t tv_sec; /* seconds */
1376 long tv_nsec; /* nanoseconds */
1381 \caption{La struttura \var{timespec} di \func{nanosleep}.}
1382 \label{fig:sig_timespec_def}
1385 In realtà è possibile ottenere anche pause più precise del centesimo di
1386 secondo usando politiche di scheduling real time come \macro{SCHED\_FIFO} o
1387 \macro{SCHED\_RR}; in tal caso infatti il meccanismo di scheduling ordinario
1388 viene evitato, e si raggiungono pause fino ai 2~ms con precisioni del $\mu$s.
1392 \subsection{Un esempio elementare}
1393 \label{sec:sig_sigchld}
1395 Un semplice esempio per illustrare il funzionamento di un manipolatore di
1396 segnale è quello della gestione di \macro{SIGCHLD}. Abbiamo visto in
1397 \secref{sec:proc_termination} che una delle azioni eseguite dal kernel alla
1398 conclusione di un processo è quella di inviare questo segnale al
1399 padre.\footnote{in realtà in SRV4 eredita la semantica di System V, in cui il
1400 segnale si chiama \macro{SIGCLD} e viene trattato in maniera speciale; in
1401 System V infatti se si setta esplicitamente l'azione a \macro{SIG\_IGN} il
1402 segnale non viene generato ed il sistema non genera zombie (lo stato di
1403 terminazione viene scartato senza dover chiamare una \func{wait}). L'azione
1404 di default è sempre quella di ignorare il segnale, ma non attiva questo
1405 comportamento. Linux, come BSD e POSIX, non supporta questa semantica ed usa
1406 il nome di \macro{SIGCLD} come sinonimo di \macro{SIGCHLD}.} In generale
1407 dunque, quando non interessa elaborare lo stato di uscita di un processo, si
1408 può completare la gestione della terminazione installando un manipolatore per
1409 \macro{SIGCHLD} il cui unico compito sia quello chiamare \func{waitpid} per
1410 completare la procedura di terminazione in modo da evitare la formazione di
1413 In \figref{fig:sig_sigchld_handl} è mostrato il codice della nostra
1414 implementazione del manipolatore; se aggiungiamo al codice di
1415 \file{ForkTest.c} l'intallazione di questo manipolatore potremo verificare che
1416 ripetendo l'esempio visto in \secref{sec:proc_termination} che non si ha più
1417 la creazione di zombie.
1420 % naturale usare un esempio che ci permette di concludere la trattazione della
1421 % terminazione dei processi.
1422 % In questo caso si è tratterà di illustrare un esempio relativo ad un
1423 % manipolatore per che è previsto ritornare,
1426 \begin{figure}[!htb]
1427 \footnotesize \centering
1428 \begin{minipage}[c]{15cm}
1429 \begin{lstlisting}{}
1430 #include <errno.h> /* error simbol definitions */
1431 #include <signal.h> /* signal handling declarations */
1432 #include <sys/types.h>
1433 #include <sys/wait.h>
1436 void Hand_CHLD(int sig)
1441 /* save errno current value */
1446 pid = waitpid(WAIT_ANY, &status, WNOHANG);
1448 debug("child %d terminated with status %x\n", pid, status);
1450 } while ((pid > 0) && (errno == EINTR));
1451 /* restore errno value */
1459 \caption{Un manipolatore per il segnale \texttt{SIGCHLD}.}
1460 \label{fig:sig_sigchld_handl}
1463 Il codice del manipolatore è di lettura immediata; come buona norma di
1464 programmazione (si ricordi quanto accennato \secref{sec:sys_errno}) si
1465 comincia (\texttt{\small 12-13}) con il salvare lo stato corrente di
1466 \var{errno}, in modo da poterlo ripristinare prima del ritorno del
1467 manipolatore (\texttt{\small 22-23}). In questo modo si preserva il valore
1468 della variabile visto dal corso di esecuzione principale del processo, che
1469 sarebbe altrimenti sarebbe sovrascritto dal valore restituito nella successiva
1470 chiamata di \func{wait}.
1472 Il compito principale del manipolatore è quello di ricevere lo stato di
1473 terminazione del processo, cosa che viene eseguita nel ciclo in
1474 (\texttt{\small 15-21}). Il ciclo è necessario a causa di una caratteristica
1475 fondamentale della gestione dei segnali: abbiamo già accennato come fra la
1476 generazione di un segnale e l'esecuzione del manipolatore possa passare un
1477 certo lasso di tempo e niente ci assicura che il manipolatore venga eseguito
1478 prima della generazione di ulteriori segnali dello stesso tipo. In questo caso
1479 normalmente i segnali segnali successivi vengono ``fusi'' col primo ed al
1480 processo ne viene recapitato soltanto uno.
1482 Questo può essere un caso comune proprio con \macro{SIGCHLD}, qualora capiti
1483 che molti processi figli terminino in rapida successione. Esso inoltre si
1484 presenta tutte le volte che un segnale viene bloccato: per quanti siano i
1485 segnali emessi durante il periodo di blocco, una volta che quest'ultimo sarà
1486 rimosso sarà recapitato un solo segnale.
1488 Allora nel caso della terminazione dei processi figli, se si chiamasse
1489 \func{waitpid} una sola volta, essa leggerebbe lo stato di teminazione per un
1490 solo processo, anche se i processi terminati sono più di uno, e gli altri
1491 resterebbero in stato di zombie per un tempo indefinito.
1493 Per questo occorre ripetere la chiamata di \func{waitpid} fino a che essa non
1494 ritorni un valore nullo, segno che non resta nessun processo di cui si debba
1495 ancora ricevere lo stato di terminazione (si veda \secref{sec:proc_wait} per
1496 la sintassi della funzione). Si noti anche come la funzione venga invocata con
1497 il parametro \macro{WNOHANG} che permette di evitare il suo blocco quando
1498 tutti gli stati di terminazione sono stati ricevuti.
1502 \section{Gestione avanzata}
1503 \label{sec:sig_control}
1505 Le funzioni esaminate finora fanno riferimento ad alle modalità più elementari
1506 della gestione dei segnali; non si sono pertanto ancora prese in
1507 considerazione le tematiche più complesse, collegate alle varie race condition
1508 che i segnali possono generare e alla natura asincrona degli stessi.
1510 Affronteremo queste problematiche in questa sezione, partendo da un esempio
1511 che le evidenzi, per poi prendere in esame le varie funzioni che permettono di
1512 risolvere i problemi più complessi connessi alla programmazione con i segnali,
1513 fino a trattare le caratteristiche generali della gestione dei medesimi nella
1514 casistica ordinaria.
1517 \subsection{Alcune problematiche aperte}
1518 \label{sec:sig_example}
1520 Come accennato in \secref{sec:sig_pause_sleep} è possibile implementare
1521 \func{sleep} a partire da dall'uso di \func{pause} e \func{alarm}. A prima
1522 vista questo può sembrare di implementazione immediata; ad esempio una
1523 semplice versione di \func{sleep} potrebbe essere quella illustrata in
1524 \figref{fig:sig_sleep_wrong}.
1527 Dato che è nostra intenzione utilizzare \macro{SIGALARM} il primo passo della
1528 nostra implementazione di sarà quello di installare il relativo manipolatore
1529 salvando il precedente (\texttt{\small 4-7}). Si effettuerà poi una chiamata
1530 ad \func{alarm} per specificare il tempo d'attesa per l'invio del segnale a
1531 cui segue la chiamata a \func{pause} per fermare il programma (\texttt{\small
1532 8-9}) fino alla sua ricezione. Al ritorno di \func{pause}, causato dal
1533 ritorno del manipolatore (\texttt{\small 15-23}), si ripristina il
1534 manipolatore originario (\texttt{\small 10-11}) restituendo l'eventuale tempo
1535 rimanente (\texttt{\small 12-13}) che potrà essere diverso da zero qualora
1536 l'interruzione di \func{pause} venisse causata da un altro segnale.
1538 \begin{figure}[!htb]
1539 \footnotesize \centering
1540 \begin{minipage}[c]{15cm}
1541 \begin{lstlisting}{}
1542 unsigned int sleep(unsigned int seconds)
1544 signandler_t prev_handler;
1545 if ((prev_handler = signal(SIGALRM, alarm_hand)) == SIG_ERR) {
1546 printf("Cannot set handler for alarm\n");
1551 /* restore previous signal handler */
1552 signal(SIGALRM, prev_handler);
1553 /* remove alarm, return remaining time */
1556 void alarm_hand(int sig)
1558 /* check if the signal is the right one */
1559 if (sig != SIGALRM) { /* if not exit with error */
1560 printf("Something wrong, handler for SIGALRM\n");
1562 } else { /* do nothing, just interrupt pause */
1569 \caption{Una implementazione pericolosa di \func{sleep}.}
1570 \label{fig:sig_sleep_wrong}
1573 Questo codice però, a parte il non gestire il caso in cui si è avuta una
1574 precedente chiamata a \func{alarm} (che si è tralasciato per brevità),
1575 presenta una pericolosa race condition. Infatti se il processo viene
1576 interrotto fra la chiamata di \func{alarm} e \func{pause} può capitare (ad
1577 esempio se il sistema è molto carico) che il tempo di attesa scada prima
1578 dell'esecuzione quest'ultima, cosicchè essa sarebbe eseguita dopo l'arrivo di
1579 \macro{SIGALRM}. In questo caso ci si troverebbe di fronte ad un deadlock, in
1580 quanto \func{pause} non verrebbe mai più interrotta (se non in caso di un
1583 Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
1584 SVr2) usando la funzione \func{longjump} (vedi \secref{sec:proc_longjmp}) per
1585 uscire dal manipolatore; in questo modo, con una condizione sullo stato di
1586 uscita di quest'ultima, si può evitare la chiamata a \func{pause}, usando un
1587 codice del tipo di quello riportato in \figref{fig:sig_sleep_incomplete}.
1589 \begin{figure}[!htb]
1590 \footnotesize \centering
1591 \begin{minipage}[c]{15cm}
1592 \begin{lstlisting}{}
1593 static jmp_buff alarm_return;
1594 unsigned int sleep(unsigned int seconds)
1596 signandler_t prev_handler;
1597 if ((prev_handler = signal(SIGALRM, alarm_hand)) == SIG_ERR) {
1598 printf("Cannot set handler for alarm\n");
1601 if (setjmp(alarm_return) == 0) { /* if not returning from handler */
1602 alarm(second); /* call alarm */
1603 pause(); /* then wait */
1605 /* restore previous signal handler */
1606 signal(SIGALRM, prev_handler);
1607 /* remove alarm, return remaining time */
1610 void alarm_hand(int sig)
1612 /* check if the signal is the right one */
1613 if (sig != SIGALRM) { /* if not exit with error */
1614 printf("Something wrong, handler for SIGALRM\n");
1616 } else { /* return in main after the call to pause */
1617 longjump(alarm_return, 1);
1623 \caption{Una implementazione ancora malfunzionante di \func{sleep}.}
1624 \label{fig:sig_sleep_incomplete}
1627 In questo caso il manipolatore (\texttt{\small 18-26}) non ritorna come in
1628 \figref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 24}) per
1629 rientrare nel corpo principale del programma; dato che in questo caso il
1630 valore di uscita di \func{setjmp} è 1 grazie alla condizione in
1631 (\texttt{\small 9-12}) si evita comunque che \func{pause} sia chiamata a
1634 Ma anche questa implementazione comporta dei problemi; in questo caso infatti
1635 non viene gestita correttamente l'interazione con gli altri segnali; se
1636 infatti il segnale di allarme interrompe un altro manipolatore, in questo caso
1637 l'esecuzione non riprenderà nel manipolatore in questione, ma nel ciclo
1638 principale, interrompendone inopportunamente l'esecuzione. Lo stesso tipo di
1639 problemi si presenterebbero se si volesse usare \func{alarm} per stabilire un
1640 timeout su una qualunque system call bloccante.
1642 Un secondo esempio è quello in cui si usa il segnale per notificare una
1643 quelche forma di evento; in genere quello che si fa in questo caso è settare
1644 nel manipolatore un opportuno flag da controllare nel corpo principale del
1645 programma (con un codice del tipo di quello riportato in
1646 \secref{fig:sig_event_wrong}.
1648 \begin{figure}[!htb]
1649 \footnotesize \centering
1650 \begin{minipage}[c]{15cm}
1651 \begin{lstlisting}{}
1657 if (flag) { /* test if signal occurred */
1658 flag = 0; /* reset flag */
1659 do_response(); /* do things */
1661 do_other(); /* do other things */
1665 void alarm_hand(int sig)
1674 \caption{Un esempio non funzionante del codice per il controllo di un
1675 evento generato da un segnale.}
1676 \label{fig:sig_event_wrong}
1679 La logica è quella di far settare al manipolatore (\texttt{\small 14-19}) una
1680 variabile globale preventivamente inizializzata nel programma principale, il
1681 quale potrà determinare, osservandone il contenuto, l'occorrenza o meno del
1682 segnale, e prendere le relative azioni conseguenti (\texttt{\small 6-11}).
1684 Questo è il tipico esempio di caso, già citato in \secref{sec:proc_race_cond},
1685 in cui si genera una race condition; se infatti il segnale arriva
1686 immediatamente dopo l'esecuzione del controllo (\texttt{\small 6}) ma prima
1687 della cancellazione del flag (\texttt{\small 7}), la sua occorrenza sarà
1690 Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono
1691 funzioni più sofisticate della semplice interfaccia dei primi sistemi Unix,
1692 che permettano di gestire tutti i possibili aspetti con cui un processo deve
1693 reagire alla ricezione di un segnale.
1697 \subsection{I \textit{signal set}}
1698 \label{sec:sig_sigset}
1700 Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali
1701 dei primi Unix, nate con la semantica inaffidabile, hanno dei limiti non
1702 superabili; in particolare non è prevista nessuna funzione che permetta di
1703 gestire gestire il blocco dei segnali o di verificare lo stato dei segnali
1706 Per questo motivo lo standard POSIX.1, insieme alla nuova semantica dei
1707 segnali ha introdotto una interfaccia di gestione completamente nuova, che
1708 permette di ottenete un controllo molto più dettagliato. In particolare lo
1709 standard ha introdotto un nuovo tipo di dato \type{sigset\_t}, che permette di
1710 rappresentare un insieme di segnali (un \textit{signal set}, come viene
1711 usualmente chiamato), che è il tipo di dato che viene usato per gestire il
1714 In genere un \textit{signal set} è rappresentato da un intero di dimensione
1715 opportuna, di solito si pari al numero di bit dell'architettura della
1716 macchina\footnote{nel caso dei PC questo comporta un massimo di 32 segnali
1717 distinti, dato che in Linux questi sono sufficienti non c'è necessità di
1718 nessuna struttura più complicata.}, ciascun bit del quale è associato ad uno
1719 specifico segnale; in questo modo è di solito possibile implementare le
1720 operazioni direttamente con istruzioni elementari del processore; lo standard
1721 POSIX.1 definisce cinque funzioni per la manipolazione dei \textit{signal set},
1722 \func{sigemptyset}, \func{sigfillset}, \func{sigaddset}, \func{sigdelset} e
1723 \func{sigismember}, i cui prototipi sono:
1727 \funcdecl{int sigemptyset(sigset\_t *set)} Inizializza un \textit{signal set}
1730 \funcdecl{int sigfillset(sigset\_t *set)} Inizializza un \textit{signal set}
1731 pieno (con tutti i segnali).
1733 \funcdecl{int sigaddset(sigset\_t *set, int signum)} Aggiunge il segnale
1734 \param{signum} al \textit{signal set} \param{set}.
1736 \funcdecl{int sigdelset(sigset\_t *set, int signum)} Toglie il segnale
1737 \param{signum} dal \textit{signal set} \param{set}.
1739 \funcdecl{int sigismember(const sigset\_t *set, int signum)} Controlla se il
1740 segnale \param{signum} è nel \textit{signal set} \param{set}
1742 \bodydesc{Le prime quattro funzioni ritornano 0 in caso di successo, mentre
1743 \func{sigismember} ritorna 1 se \param{signum} è in \param{set} e 0
1744 altrimenti. In caso di errore tutte ritornano -1, con \var{errno} settata a
1745 \macro{EINVAL} (il solo errore possibile è che \param{signum} non sia un
1749 Dato che in generale non si può fare conto sulle caratteristiche di una
1750 implementazione (non è detto che si disponga di un numero di bit sufficienti
1751 per mettere tutti i segnali in un intero, o in \type{sigset\_t} possono essere
1752 immagazzinate ulteriori informazioni) tutte le operazioni devono essere
1753 comunque eseguite attraverso queste funzioni.
1755 In genere si usa un \textit{signal set} per specificare quali segnali si vuole
1756 bloccare, o per riottenere dalle varie funzioni di gestione la maschera dei
1757 segnali attivi. Essi possono essere definiti in due diverse maniere,
1758 aggiungendo i segnali voluti ad un insieme vuoto ottenuto con
1759 \func{sigemptyset} o togliendo quelli che non servono da un insieme completo
1760 ottenuto con \func{sigfillset}. Infine \func{sigismember} permette di vericare
1761 la presenza di uno specifico segnale in un \textit{signal set}.
1764 \subsection{La funzione \func{sigaction}}
1765 \label{sec:sig_sigaction}
1767 La funzione principale dell'interfaccia standard POSIX.1 per i segnali è
1768 \func{sigaction}, essa ha sostanzialemente le stesse funzioni di
1769 \func{signal}, permette cioè di specificare come un segnale può essere gestito
1770 da un processo. Il suo prototipo è:
1772 \begin{prototype}{signal.h}{int sigaction(int signum, const struct sigaction
1773 *act, struct sigaction *oldact)}
1775 Installa un nuovo manipolatore per il segnale \param{signum}.
1777 \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
1778 errore, nel qual caso \var{errno} assumerà i valori:
1780 \item[\macro{EINVAL}] Si è specificato un numero di segnale invalido o si è
1781 cercato di installare il manipolatore per \macro{SIGKILL} o
1783 \item[\macro{EFAULT}] Si sono specificati indirizzi non validi.
1787 La funzione serve ad installare una nuova \textsl{azione} per il segnale
1788 \param{signum}; si parla di \textsl{azione} e non di \textsl{manipolatore}
1789 come nel caso di \func{signal}, in quanto la funzione consente di specificare
1790 le varie caratteristiche della risposta al segnale, non solo la funzione del
1791 manipolatore. Per questo lo standard raccomanda di usare sempre questa
1792 funzione al posto di \func{signal} (che in genere viene definita tramite
1793 essa), in quanto offre un controllo completo su tutti gli aspetti della
1794 gestione di un segnale, sia pure al prezzo di una maggiore complessità d'uso.
1796 Se il puntatore \param{act} non è nullo, la funzione installa la nuova azione
1797 da esso specificata, se \param{oldact} non è nullo il valore dell'azione
1798 corrente viene restituito indietro. Questo permette (specificando \param{act}
1799 nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
1800 che non consente di ottenere l'azione corrente senza installarne una nuova.
1802 Entrambi i puntatori fanno riferimento alla struttura \var{sigaction}, tramite
1803 la quale si specificano tutte le caratteristiche dell'azione associata ad un
1804 segnale. Anch'essa è descritta dallo standard POSIX.1 ed in Linux è definita
1805 secondo quanto riportato in \figref{fig:sig_sigaction}. Il campo
1806 \var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
1809 \begin{figure}[!htb]
1810 \footnotesize \centering
1811 \begin{minipage}[c]{15cm}
1812 \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
1815 void (*sa_handler)(int);
1816 void (*sa_sigaction)(int, siginfo_t *, void *);
1819 void (*sa_restorer)(void);
1824 \caption{La struttura \var{sigaction}.}
1825 \label{fig:sig_sigaction}
1828 Come si può notare da quanto riportato in \figref{fig:sig_sigaction} in Linux
1829 \func{sigaction} permette di specificare il manipolatore in due forme diverse,
1830 indicate dai campi \var{sa\_handler} e \var{sa\_sigaction}; esse devono essere
1831 usate in maniera alternativa (in certe implementazioni questi vengono
1832 specificati come \ctyp{union}): la prima è quella classica usata anche con
1833 \func{signal}, la seconda permette invece di usare un manipolatore in grado di
1834 ricevere informazioni più dettagliate dal sistema (ad esempio il tipo di
1835 errore in caso di \macro{SIGFPE}), attraverso dei parametri aggiuntivi; per i
1836 dettagli si consulti la man page di \func{sigaction}).
1838 Il campo \var{sa\_mask} serve ad indicare l'insieme dei segnali che devono
1839 essere bloccati durante l'esecuzione del manipolatore, ad essi viene comunque
1840 sempre aggiunto il segnale che ne ha causato la chiamata, a meno che non si
1841 sia specificato con \var{sa\_flag} un comportamento diverso.
1843 Il valore di \var{sa\_flag} permette di specificare vari aspetti del
1844 comportamento di \func{sigaction}, e della reazione del processo ai vari
1845 segnali; i valori possibili ed il relativo significato sono riportati in
1846 \tabref{tab:sig_sa_flag}.
1851 \begin{tabular}[c]{|l|p{8cm}|}
1853 \textbf{Valore} & \textbf{Timer} \\
1856 \macro{SA\_NOCLDSTOP}& Se il segnale è \macro{SIGCHLD} allora non deve
1857 essere notificato quando il processo figlio viene fermato da uno dei
1858 segnali \macro{SIGSTOP}, \macro{SIGTSTP}, \macro{SIGTTIN} or
1860 \macro{SA\_ONESHOT} & Ristabilisce l'azione per il segnale al valore di
1861 default una volta che il manipolatore è stato lanciato, riproduce cioè il
1862 comportamento della semantica inaffidabile.\\
1863 \macro{SA\_RESETHAND}& Sinonimo di \macro{SA\_ONESHOT}. \\
1864 \macro{SA\_RESTART} & Riavvia automaticamente le \textit{slow system
1865 call} quando vengono interrotte dal suddetto segnale; riproduce cioè il
1866 comportamento standard di BSD.\\
1867 \macro{SA\_NOMASK} & Evita che il segnale corrente sia bloccato durante
1868 l'esecuzione del manipolatore.\\
1869 \macro{SA\_NODEFER} & Sinonimo di \macro{SA\_NOMASK}.\\
1870 \macro{SA\_SIGINFO} & Deve essere specificato quando si vuole usare un
1871 manipolatore in forma estesa usando \var{sa\_sigaction} al posto di
1872 \var{sa\_handler}. \\
1873 \macro{SA\_ONSTACK} & Stabilisce l'uso di uno stack alternativo per
1874 l'esecuzione del manipolatore (vedi \secref{sec:sig_altstack}).\\
1877 \caption{Valori del campo \var{sa\_flag} della struttura \var{sigaction}.}
1878 \label{tab:sig_sa_flag}
1881 Benché sia possibile usare nello stesso programma sia \func{sigaction} che
1882 \func{signal} occorre molta attenzione, in quanto le due funzioni possono
1883 interagire in maniera anomala. Infatti l'azione specificata con
1884 \var{sigaction} contiene un maggior numero di informazioni rispetto al
1885 semplice indirizzo del manipolatore restituito da \func{signal}. Per questo
1886 motivo se si usa quest'ultima per installare un manipolatore sostituendone uno
1887 precedentemente installato con \func{sigaction}, non sarà possibile effettuare
1888 un ripristino corretto dello stesso.
1890 Per questo è sempre opportuno usare \func{sigaction}, che è in grado di
1891 ripristinare correttamente un manipolatore precedente, anche se questo è stato
1892 installato con \func{signal}. In generale poi non è il caso di usare il valore
1893 di ritorno di \func{signal} come campo \var{sa\_handler}, o viceversa, dato
1894 che in certi sistemi questi possono essere diversi. In generale dunque, a meno
1895 che non si sia vincolati allo standard ISO C, è sempre il caso di evitare
1896 l'uso di \func{signal} a favore di \func{sigaction}.
1900 \subsection{La gestione del blocco dei segnali}
1901 \label{sec:sig_sigmask}
1903 Come spiegato in \secref{sec:sig_semantics} tutti i moderni sistemi unix-like
1904 permettono si bloccare temporaneamente (o di eliminare completamente, settando
1905 \macro{SIG\_IGN} come azione) la consegna dei segnali ad un processo. Questo è
1906 fatto specificando la cosiddetta \textit{signal mask} del
1907 processo\footnote{nel caso di Linux essa è mantenuta dal campo \var{blocked}
1908 della \var{task\_struct} del processo.} che viene espressa come il signal
1909 set dei segnali la cui consegna è bloccata. Abbiamo accennato in
1910 \secref{sec:proc_fork} che la \textit{signal mask} viene ereditata dal padre
1911 alla creazione di un processo figlio, e abbiamo visto al paragrafo precedente
1912 che essa può essere specificata, durante l'esecuzione di un manipolatore,
1913 attraverso l'uso dal campo \var{sa\_mask} di \var{sigaction}.
1915 Uno dei problemi evidenziatisi con l'esempio di \secref{fig:sig_event_wrong} è
1916 che in molti casi è necessario proteggere delle sezioni di codice (nel caso la
1917 sezione fra il test e la eventuale cancellazione del flag che testimoniava
1918 l'avvenuta occorrenza del segnale) in modo da essere sicuri che essi siano
1919 eseguiti senza interruzioni. Le operazioni più semplici, come l'assegnazione o
1920 il controllo di una variabile di norma (per essere sicuri si può usare il tipo
1921 \type{sig\_atomic\_t}).
1925 \subsection{Le funzioni \func{sigpending} e \func{sigsuspend}}
1926 \label{sec:sig_sigpending}
1932 \subsection{Funzioni rientranti e default dei segnali}
1933 \label{sec:sig_reentrant}
1939 %%% Local Variables:
1941 %%% TeX-master: "gapil"