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