3 %% Copyright (C) 2000-2009 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} \textit{stack}) prima
266 della terminazione. Questo può essere esaminato in seguito con un debugger
267 per investigare sulla causa dell'errore. Lo stesso avviene se i suddetti
268 segnali 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} \textit{stack} e delle variabili
353 al 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 & Timer di esecuzione scaduto. \\
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}
463 \textit{stack}. Lo stesso segnale viene generato in caso di overflow dello
464 \itindex{stack} \textit{stack} o di problemi nell'esecuzione di un gestore.
465 Se il gestore ritorna il comportamento del processo è indefinito.
466 \item[\const{SIGSEGV}] Il nome deriva da \itindex{segment~violation}
467 \textit{segment violation}, e significa che il programma sta cercando di
468 leggere o scrivere in una zona di memoria protetta al di fuori di quella che
469 gli è stata riservata dal sistema. In genere è il meccanismo della
470 protezione della memoria che si accorge dell'errore ed il kernel genera il
471 segnale. Se il gestore 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} \textit{stack}), mentre
480 \const{SIGBUS} indica l'accesso ad un indirizzo non valido, come nel caso di
481 un puntatore non allineato.
482 \item[\const{SIGABRT}] Il nome deriva da \textit{abort}. Il segnale indica che
483 il programma stesso ha rilevato un errore che viene riportato chiamando la
484 funzione \func{abort} che genera questo segnale.
485 \item[\const{SIGTRAP}] È il segnale generato da un'istruzione di breakpoint o
486 dall'attivazione del tracciamento per il processo. È usato dai programmi per
487 il debugging e un programma normale non dovrebbe ricevere questo segnale.
488 \item[\const{SIGSYS}] Sta ad indicare che si è eseguita una istruzione che
489 richiede l'esecuzione di una system call, ma si è fornito un codice
490 sbagliato per quest'ultima.
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 (vedi
567 sez.~\ref{sec:sig_alarm_abort}). Il loro comportamento predefinito è quello di
568 causare la terminazione del programma, ma con questi segnali la scelta
569 predefinita è irrilevante, in quanto il loro uso presuppone sempre la
570 necessità di un gestore. Questi segnali sono:
571 \begin{basedescript}{\desclabelwidth{2.0cm}}
572 \item[\const{SIGALRM}] Il nome sta per \textit{alarm}. Segnale la scadenza di
573 un timer misurato sul tempo reale o sull'orologio di sistema. È normalmente
574 usato dalla funzione \func{alarm}.
576 \item[\const{SIVGTALRM}] Il nome sta per \textit{virtual alarm}. È analogo al
577 precedente ma segnala la scadenza di un timer sul tempo di CPU usato dal
580 \item[\const{SIGPROF}] Il nome sta per \textit{profiling}. Indica la scadenza
581 di un timer che misura sia il tempo di CPU speso direttamente dal processo
582 che quello che il sistema ha speso per conto di quest'ultimo. In genere
583 viene usato dagli strumenti che servono a fare la profilazione dell'utilizzo
584 del tempo di CPU da parte del processo.
588 \subsection{I segnali di I/O asincrono}
589 \label{sec:sig_asyncio}
591 Questi segnali operano in congiunzione con le funzioni di I/O asincrono. Per
592 questo occorre comunque usare \func{fcntl} per abilitare un file descriptor a
593 generare questi segnali. L'azione predefinita è di essere ignorati. Questi
595 \begin{basedescript}{\desclabelwidth{2.0cm}}
596 \item[\const{SIGIO}] Questo segnale viene inviato quando un file descriptor è
597 pronto per eseguire dell'input/output. In molti sistemi solo i
598 socket e i terminali possono generare questo segnale, in Linux
599 questo può essere usato anche per i file, posto che la \func{fcntl} abbia
602 \item[\const{SIGURG}] Questo segnale è inviato quando arrivano dei dati
603 urgenti o \itindex{out-of-band} \textit{out-of-band} su di un
604 socket; per maggiori dettagli al proposito si veda
605 sez.~\ref{sec:TCP_urgent_data}.
607 \item[\const{SIGPOLL}] Questo segnale è equivalente a \const{SIGIO}, è
608 definito solo per compatibilità con i sistemi System V.
612 \subsection{I segnali per il controllo di sessione}
613 \label{sec:sig_job_control}
615 Questi sono i segnali usati dal controllo delle sessioni e dei processi, il
616 loro uso è specializzato e viene trattato in maniera specifica nelle sezioni
617 in cui si trattano gli argomenti relativi. Questi segnali sono:
618 \begin{basedescript}{\desclabelwidth{2.0cm}}
619 \item[\const{SIGCHLD}] Questo è il segnale mandato al processo padre quando un
620 figlio termina o viene fermato. L'azione predefinita è di ignorare il
621 segnale, la sua gestione è trattata in sez.~\ref{sec:proc_wait}.
623 \item[\const{SIGCLD}] Per Linux questo è solo un segnale identico al
624 precedente, il nome è obsoleto e andrebbe evitato.
626 \item[\const{SIGCONT}] Il nome sta per \textit{continue}. Il segnale viene
627 usato per fare ripartire un programma precedentemente fermato da
628 \const{SIGSTOP}. Questo segnale ha un comportamento speciale, e fa sempre
629 ripartire il processo prima della sua consegna. Il comportamento predefinito
630 è di fare solo questo; il segnale non può essere bloccato. Si può anche
631 installare un gestore, ma il segnale provoca comunque il riavvio del
634 La maggior pare dei programmi non hanno necessità di intercettare il
635 segnale, in quanto esso è completamente trasparente rispetto all'esecuzione
636 che riparte senza che il programma noti niente. Si possono installare dei
637 gestori per far si che un programma produca una qualche azione speciale
638 se viene fermato e riavviato, come per esempio riscrivere un prompt, o
640 \item[\const{SIGSTOP}] Il segnale ferma un processo (lo porta cioè in uno
641 stato di sleep, vedi sez.~\ref{sec:proc_sched}); il segnale non può essere né
642 intercettato, né ignorato, né bloccato.
644 \item[\const{SIGTSTP}] Il nome sta per \textit{interactive stop}. Il segnale
645 ferma il processo interattivamente, ed è generato dal carattere SUSP
646 (prodotto dalla combinazione \cmd{C-z}), ed al contrario di
647 \const{SIGSTOP} può essere intercettato e ignorato. In genere un programma
648 installa un gestore per questo segnale quando vuole lasciare il sistema
649 o il terminale in uno stato definito prima di fermarsi; se per esempio un
650 programma ha disabilitato l'eco sul terminale può installare un gestore
651 per riabilitarlo prima di fermarsi.
653 \item[\const{SIGTTIN}] Un processo non può leggere dal terminale se esegue una
654 sessione di lavoro in \textit{background}. Quando un processo in background
655 tenta di leggere da un terminale viene inviato questo segnale a tutti i
656 processi della sessione di lavoro. L'azione predefinita è di fermare il
657 processo. L'argomento è trattato in
658 sez.~\ref{sec:sess_job_control_overview}.
660 \item[\const{SIGTTOU}] Segnale analogo al precedente \const{SIGTTIN}, ma
661 generato quando si tenta di scrivere o modificare uno dei modi del
662 terminale. L'azione predefinita è di fermare il processo, l'argomento è
663 trattato in sez.~\ref{sec:sess_job_control_overview}.
667 \subsection{I segnali di operazioni errate}
668 \label{sec:sig_oper_error}
670 Questi segnali sono usati per riportare al programma errori generati da
671 operazioni da lui eseguite; non indicano errori del programma quanto errori
672 che impediscono il completamento dell'esecuzione dovute all'interazione con il
673 resto del sistema. L'azione predefinita di questi segnali è di terminare il
674 processo, questi segnali sono:
675 \begin{basedescript}{\desclabelwidth{2.0cm}}
676 \item[\const{SIGPIPE}] Sta per \textit{Broken pipe}. Se si usano delle pipe,
677 (o delle FIFO o dei socket) è necessario, prima che un processo inizi a
678 scrivere su una di esse, che un altro l'abbia aperta in lettura (si veda
679 sez.~\ref{sec:ipc_pipes}). Se il processo in lettura non è partito o è
680 terminato inavvertitamente alla scrittura sulla pipe il kernel genera questo
681 segnale. Se il segnale è bloccato, intercettato o ignorato la chiamata che
682 lo ha causato fallisce, restituendo l'errore \errcode{EPIPE}.
683 \item[\const{SIGLOST}] Sta per \textit{Resource lost}. Tradizionalmente è il
684 segnale che viene generato quando si perde un advisory lock su un file su
685 NFS perché il server NFS è stato riavviato. Il progetto GNU lo utilizza per
686 indicare ad un client il crollo inaspettato di un server. In Linux è
687 definito come sinonimo di \const{SIGIO}.\footnote{ed è segnalato come BUG
688 nella pagina di manuale.}
689 \item[\const{SIGXCPU}] Sta per \textit{CPU time limit exceeded}. Questo
690 segnale è generato quando un processo eccede il limite impostato per il
691 tempo di CPU disponibile, vedi sez.~\ref{sec:sys_resource_limit}.
692 \item[\const{SIGXFSZ}] Sta per \textit{File size limit exceeded}. Questo
693 segnale è generato quando un processo tenta di estendere un file oltre le
694 dimensioni specificate dal limite impostato per le dimensioni massime di un
695 file, vedi sez.~\ref{sec:sys_resource_limit}.
699 \subsection{Ulteriori segnali}
700 \label{sec:sig_misc_sig}
702 Raccogliamo qui infine una serie di segnali che hanno scopi differenti non
703 classificabili in maniera omogenea. Questi segnali sono:
704 \begin{basedescript}{\desclabelwidth{2.0cm}}
705 \item[\const{SIGUSR1}] Insieme a \const{SIGUSR2} è un segnale a disposizione
706 dell'utente che lo può usare per quello che vuole. Viene generato solo
707 attraverso l'invocazione della funzione \func{kill}. Entrambi i segnali
708 possono essere utili per implementare una comunicazione elementare fra
709 processi diversi, o per eseguire a richiesta una operazione utilizzando un
710 gestore. L'azione predefinita è di terminare il processo.
711 \item[\const{SIGUSR2}] È il secondo segnale a disposizione degli utenti. Vedi
712 quanto appena detto per \const{SIGUSR1}.
713 \item[\const{SIGWINCH}] Il nome sta per \textit{window (size) change} e viene
714 generato in molti sistemi (GNU/Linux compreso) quando le dimensioni (in
715 righe e colonne) di un terminale vengono cambiate. Viene usato da alcuni
716 programmi testuali per riformattare l'uscita su schermo quando si cambia
717 dimensione a quest'ultimo. L'azione predefinita è di essere ignorato.
718 \item[\const{SIGINFO}] Il segnale indica una richiesta di informazioni. È
719 usato con il controllo di sessione, causa la stampa di informazioni da parte
720 del processo leader del gruppo associato al terminale di controllo, gli
721 altri processi lo ignorano.
725 \subsection{Le funzioni \func{strsignal} e \func{psignal}}
726 \label{sec:sig_strsignal}
728 Per la descrizione dei segnali il sistema mette a disposizione due funzioni
729 che stampano un messaggio di descrizione dato il numero. In genere si usano
730 quando si vuole notificare all'utente il segnale ricevuto (nel caso di
731 terminazione di un processo figlio o di un gestore che gestisce più segnali);
732 la prima funzione, \funcd{strsignal}, è una estensione GNU, accessibile avendo
733 definito \macro{\_GNU\_SOURCE}, ed è analoga alla funzione \func{strerror} (si
734 veda sez.~\ref{sec:sys_strerror}) per gli errori:
735 \begin{prototype}{string.h}{char *strsignal(int signum)}
736 Ritorna il puntatore ad una stringa che contiene la descrizione del segnale
739 \noindent dato che la stringa è allocata staticamente non se ne deve
740 modificare il contenuto, che resta valido solo fino alla successiva chiamata
741 di \func{strsignal}. Nel caso si debba mantenere traccia del messaggio sarà
744 La seconda funzione, \funcd{psignal}, deriva da BSD ed è analoga alla funzione
745 \func{perror} descritta sempre in sez.~\ref{sec:sys_strerror}; il suo prototipo
747 \begin{prototype}{signal.h}{void psignal(int sig, const char *s)}
748 Stampa sullo standard error un messaggio costituito dalla stringa \param{s},
749 seguita da due punti ed una descrizione del segnale indicato da \param{sig}.
752 Una modalità alternativa per utilizzare le descrizioni restituite da
753 \func{strsignal} e \func{psignal} è quello di usare la variabile
754 \var{sys\_siglist}, che è definita in \file{signal.h} e può essere acceduta
755 con la dichiarazione:
756 \includecodesnip{listati/siglist.c}
758 L'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
759 indicizzate per numero di segnale, per cui una chiamata del tipo di \code{char
760 *decr = strsignal(SIGINT)} può essere sostituita dall'equivalente \code{char
761 *decr = sys\_siglist[SIGINT]}.
765 \section{La gestione di base dei segnali}
766 \label{sec:sig_management}
768 I segnali sono il primo e più classico esempio di eventi asincroni, cioè di
769 eventi che possono accadere in un qualunque momento durante l'esecuzione di un
770 programma. Per questa loro caratteristica la loro gestione non può essere
771 effettuata all'interno del normale flusso di esecuzione dello stesso, ma è
772 delegata appunto agli eventuali gestori che si sono installati.
774 In questa sezione vedremo come si effettua la gestione dei segnali, a partire
775 dalla loro interazione con le system call, passando per le varie funzioni che
776 permettono di installare i gestori e controllare le reazioni di un processo
777 alla loro occorrenza.
780 \subsection{Il comportamento generale del sistema}
781 \label{sec:sig_gen_beha}
783 Abbiamo già trattato in sez.~\ref{sec:sig_intro} le modalità con cui il sistema
784 gestisce l'interazione fra segnali e processi, ci resta da esaminare però il
785 comportamento delle system call; in particolare due di esse, \func{fork} ed
786 \func{exec}, dovranno essere prese esplicitamente in considerazione, data la
787 loro stretta relazione con la creazione di nuovi processi.
789 Come accennato in sez.~\ref{sec:proc_fork} quando viene creato un nuovo
790 processo esso eredita dal padre sia le azioni che sono state impostate per i
791 singoli segnali, che la maschera dei segnali bloccati (vedi
792 sez.~\ref{sec:sig_sigmask}). Invece tutti i segnali pendenti e gli allarmi
793 vengono cancellati; essi infatti devono essere recapitati solo al padre, al
794 figlio dovranno arrivare solo i segnali dovuti alle sue azioni.
796 Quando si mette in esecuzione un nuovo programma con \func{exec} (si ricordi
797 quanto detto in sez.~\ref{sec:proc_exec}) tutti i segnali per i quali è stato
798 installato un gestore vengono reimpostati a \const{SIG\_DFL}. Non ha più
799 senso infatti fare riferimento a funzioni definite nel programma originario,
800 che non sono presenti nello spazio di indirizzi del nuovo programma.
802 Si noti che questo vale solo per le azioni per le quali è stato installato un
803 gestore; viene mantenuto invece ogni eventuale impostazione dell'azione a
804 \const{SIG\_IGN}. Questo permette ad esempio alla shell di impostare ad
805 \const{SIG\_IGN} le risposte per \const{SIGINT} e \const{SIGQUIT} per i
806 programmi eseguiti in background, che altrimenti sarebbero interrotti da una
807 successiva pressione di \texttt{C-c} o \texttt{C-y}.
809 Per quanto riguarda il comportamento di tutte le altre system call si danno
810 sostanzialmente due casi, a seconda che esse siano \index{system~call~lente}
811 \textsl{lente} (\textit{slow}) o \textsl{veloci} (\textit{fast}). La gran
812 parte di esse appartiene a quest'ultima categoria, che non è influenzata
813 dall'arrivo di un segnale. Esse sono dette \textsl{veloci} in quanto la loro
814 esecuzione è sostanzialmente immediata; la risposta al segnale viene sempre
815 data dopo che la system call è stata completata, in quanto attendere per
816 eseguire un gestore non comporta nessun inconveniente.
818 In alcuni casi però alcune system call (che per questo motivo vengono chiamate
819 \textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può
820 attendere la conclusione della system call, perché questo renderebbe
821 impossibile una risposta pronta al segnale, per cui il gestore viene
822 eseguito prima che la system call sia ritornata. Un elenco dei casi in cui si
823 presenta questa situazione è il seguente:
825 \item la lettura da file che possono bloccarsi in attesa di dati non ancora
826 presenti (come per certi \index{file!di~dispositivo} file di dispositivo, i
828 \item la scrittura sugli stessi file, nel caso in cui dati non possano essere
829 accettati immediatamente (di nuovo comune per i socket);
830 \item l'apertura di un file di dispositivo che richiede operazioni non
831 immediate per una risposta (ad esempio l'apertura di un nastro che deve
833 \item le operazioni eseguite con \func{ioctl} che non è detto possano essere
834 eseguite immediatamente;
835 \item le funzioni di intercomunicazione che si bloccano in attesa di risposte
837 \item la funzione \func{pause} (usata appunto per attendere l'arrivo di un
839 \item la funzione \func{wait} (se nessun processo figlio è ancora terminato).
842 In questo caso si pone il problema di cosa fare una volta che il gestore sia
843 ritornato. La scelta originaria dei primi Unix era quella di far ritornare
844 anche la system call restituendo l'errore di \errcode{EINTR}. Questa è a
845 tutt'oggi una scelta corrente, ma comporta che i programmi che usano dei
846 gestori controllino lo stato di uscita delle funzioni che eseguono una system
847 call lenta per ripeterne la chiamata qualora l'errore fosse questo.
849 Dimenticarsi di richiamare una system call interrotta da un segnale è un
850 errore comune, tanto che le \acr{glibc} provvedono una macro
851 \code{TEMP\_FAILURE\_RETRY(expr)} che esegue l'operazione automaticamente,
852 ripetendo l'esecuzione dell'espressione \var{expr} fintanto che il risultato
853 non è diverso dall'uscita con un errore \errcode{EINTR}.
855 La soluzione è comunque poco elegante e BSD ha scelto un approccio molto
856 diverso, che è quello di fare ripartire automaticamente una system call
857 interrotta invece di farla fallire. In questo caso ovviamente non c'è bisogno
858 di preoccuparsi di controllare il codice di errore; si perde però la
859 possibilità di eseguire azioni specifiche all'occorrenza di questa particolare
862 Linux e le \acr{glibc} consentono di utilizzare entrambi gli approcci,
863 attraverso una opportuna opzione di \func{sigaction} (vedi
864 sez.~\ref{sec:sig_sigaction}). È da chiarire comunque che nel caso di
865 interruzione nel mezzo di un trasferimento parziale di dati, le system call
866 ritornano sempre indicando i byte trasferiti.
869 \subsection{La funzione \func{signal}}
870 \label{sec:sig_signal}
872 L'interfaccia più semplice per la gestione dei segnali è costituita dalla
873 funzione \funcd{signal} che è definita fin dallo standard ANSI C.
874 Quest'ultimo però non considera sistemi multitasking, per cui la definizione è
875 tanto vaga da essere del tutto inutile in un sistema Unix; è questo il motivo
876 per cui ogni implementazione successiva ne ha modificato e ridefinito il
877 comportamento, pur mantenendone immutato il prototipo\footnote{in realtà in
878 alcune vecchie implementazioni (SVr4 e 4.3+BSD in particolare) vengono usati
879 alcuni argomenti aggiuntivi per definire il comportamento della funzione,
880 vedremo in sez.~\ref{sec:sig_sigaction} che questo è possibile usando la
881 funzione \func{sigaction}.} che è:
882 \begin{prototype}{signal.h}
883 {sighandler\_t signal(int signum, sighandler\_t handler)}
885 Installa la funzione di gestione \param{handler} (il gestore) per il
886 segnale \param{signum}.
888 \bodydesc{La funzione ritorna il precedente gestore in caso di successo
889 o \const{SIG\_ERR} in caso di errore.}
892 In questa definizione si è usato un tipo di dato, \type{sighandler\_t}, che è
893 una estensione GNU, definita dalle \acr{glibc}, che permette di riscrivere il
894 prototipo di \func{signal} nella forma appena vista, molto più leggibile di
895 quanto non sia la versione originaria, che di norma è definita come:
896 \includecodesnip{listati/signal.c}
897 questa infatti, per la poca chiarezza della sintassi del C quando si vanno a
898 trattare puntatori a funzioni, è molto meno comprensibile. Da un confronto
899 con il precedente prototipo si può dedurre la definizione di
900 \type{sighandler\_t} che è:
901 \includecodesnip{listati/sighandler_t.c}
902 e cioè un puntatore ad una funzione \ctyp{void} (cioè senza valore di ritorno)
903 e che prende un argomento di tipo \ctyp{int}.\footnote{si devono usare le
904 parentesi intorno al nome della funzione per via delle precedenze degli
905 operatori del C, senza di esse si sarebbe definita una funzione che ritorna
906 un puntatore a \ctyp{void} e non un puntatore ad una funzione \ctyp{void}.}
907 La funzione \func{signal} quindi restituisce e prende come secondo argomento
908 un puntatore a una funzione di questo tipo, che è appunto la funzione che
909 verrà usata come gestore del segnale.
911 Il numero di segnale passato nell'argomento \param{signum} può essere indicato
912 direttamente con una delle costanti definite in sez.~\ref{sec:sig_standard}.
913 L'argomento \param{handler} che indica il gestore invece, oltre all'indirizzo
914 della funzione da chiamare all'occorrenza del segnale, può assumere anche i
915 due valori costanti \const{SIG\_IGN} e \const{SIG\_DFL}; il primo indica che
916 il segnale deve essere ignorato,\footnote{si ricordi però che i due segnali
917 \const{SIGKILL} e \const{SIGSTOP} non possono essere né ignorati né
918 intercettati; l'uso di \const{SIG\_IGN} per questi segnali non ha alcun
919 effetto.} mentre il secondo ripristina l'azione predefinita.\footnote{e
920 serve a tornare al comportamento di default quando non si intende più
921 gestire direttamente un segnale.}
923 La funzione restituisce l'indirizzo dell'azione precedente, che può essere
924 salvato per poterlo ripristinare (con un'altra chiamata a \func{signal}) in un
925 secondo tempo. Si ricordi che se si imposta come azione \const{SIG\_IGN} (o si
926 imposta un \const{SIG\_DFL} per un segnale la cui azione predefinita è di
927 essere ignorato), tutti i segnali pendenti saranno scartati, e non verranno
930 L'uso di \func{signal} è soggetto a problemi di compatibilità, dato che essa
931 si comporta in maniera diversa per sistemi derivati da BSD o da System V. In
932 questi ultimi infatti la funzione è conforme al comportamento originale dei
933 primi Unix in cui il gestore viene disinstallato alla sua chiamata, secondo la
934 semantica inaffidabile; anche Linux seguiva questa convenzione con le vecchie
935 librerie del C come le \acr{libc4} e le \acr{libc5}.\footnote{nelle
936 \acr{libc5} esiste però la possibilità di includere \file{bsd/signal.h} al
937 posto di \file{signal.h}, nel qual caso la funzione \func{signal} viene
938 ridefinita per seguire la semantica affidabile usata da BSD.}
940 Al contrario BSD segue la semantica affidabile, non disinstallando il gestore
941 e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo delle
942 \acr{glibc} dalla versione 2 anche Linux è passato a questo comportamento. Il
943 comportamento della versione originale della funzione, il cui uso è deprecato
944 per i motivi visti in sez.~\ref{sec:sig_semantics}, può essere ottenuto
945 chiamando \func{sysv\_signal}, una volta che si sia definita la macro
946 \macro{\_XOPEN\_SOURCE}. In generale, per evitare questi problemi, l'uso di
947 \func{signal}, che tra l'altro ha un comportamento indefinito in caso di
948 processo \itindex{thread} multi-\textit{thread}, è da evitare; tutti i nuovi
949 programmi dovrebbero usare \func{sigaction}.
951 È da tenere presente che, seguendo lo standard POSIX, il comportamento di un
952 processo che ignora i segnali \const{SIGFPE}, \const{SIGILL}, o
953 \const{SIGSEGV} (qualora questi non originino da una chiamata ad una
954 \func{kill} o ad una \func{raise}) è indefinito. Un gestore che ritorna da
955 questi segnali può dare luogo ad un ciclo infinito.
958 \subsection{Le funzioni \func{kill} e \func{raise}}
959 \label{sec:sig_kill_raise}
961 Come precedentemente accennato in sez.~\ref{sec:sig_types}, un segnale può
962 anche essere generato direttamente nell'esecuzione di un programma, attraverso
963 la chiamata ad una opportuna system call. Le funzioni che si utilizzano di
964 solito per inviare un segnale generico ad un processo sono due: \func{raise} e
967 La prima funzione è \funcd{raise}, che è definita dallo standard ANSI C, e
968 serve per inviare un segnale al processo corrente,\footnote{non prevedendo la
969 presenza di un sistema multiutente lo standard ANSI C non poteva che
970 definire una funzione che invia il segnale al programma in esecuzione. Nel
971 caso di Linux questa viene implementata come funzione di compatibilità.} il
973 \begin{prototype}{signal.h}{int raise(int sig)}
974 Invia il segnale \param{sig} al processo corrente.
976 \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
977 errore, il solo errore restituito è \errval{EINVAL} qualora si sia
978 specificato un numero di segnale invalido.}
981 Il valore di \param{sig} specifica il segnale che si vuole inviare e può
982 essere specificato con una delle macro definite in
983 sez.~\ref{sec:sig_classification}. In genere questa funzione viene usata per
984 riprodurre il comportamento predefinito di un segnale che sia stato
985 intercettato. In questo caso, una volta eseguite le operazioni volute, il
986 gestore dovrà prima reinstallare l'azione predefinita, per poi attivarla
987 chiamando \func{raise}.
989 Mentre \func{raise} è una funzione di libreria, quando si vuole inviare un
990 segnale generico ad un processo occorre utilizzare la apposita system call,
991 questa può essere chiamata attraverso la funzione \funcd{kill}, il cui
994 \headdecl{sys/types.h}
996 \funcdecl{int kill(pid\_t pid, int sig)} Invia il segnale \param{sig} al
997 processo specificato con \param{pid}.
999 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
1000 errore nel qual caso \var{errno} assumerà uno dei valori:
1002 \item[\errcode{EINVAL}] il segnale specificato non esiste.
1003 \item[\errcode{ESRCH}] il processo selezionato non esiste.
1004 \item[\errcode{EPERM}] non si hanno privilegi sufficienti ad inviare il
1009 Lo standard POSIX prevede che il valore 0 per \param{sig} sia usato per
1010 specificare il segnale nullo. Se la funzione viene chiamata con questo valore
1011 non viene inviato nessun segnale, ma viene eseguito il controllo degli errori,
1012 in tal caso si otterrà un errore \errcode{EPERM} se non si hanno i permessi
1013 necessari ed un errore \errcode{ESRCH} se il processo specificato non esiste.
1014 Si tenga conto però che il sistema ricicla i \acr{pid} (come accennato in
1015 sez.~\ref{sec:proc_pid}) per cui l'esistenza di un processo non significa che
1016 esso sia realmente quello a cui si intendeva mandare il segnale.
1018 Il valore dell'argomento \param{pid} specifica il processo (o i processi) di
1019 destinazione a cui il segnale deve essere inviato e può assumere i valori
1020 riportati in tab.~\ref{tab:sig_kill_values}.
1022 Si noti pertanto che la funzione \code{raise(sig)} può essere definita in
1023 termini di \func{kill}, ed è sostanzialmente equivalente ad una
1024 \code{kill(getpid(), sig)}. Siccome \func{raise}, che è definita nello
1025 standard ISO C, non esiste in alcune vecchie versioni di Unix, in generale
1026 l'uso di \func{kill} finisce per essere più portabile.
1028 Una seconda funzione che può essere definita in termini di \func{kill} è
1029 \funcd{killpg}, che è sostanzialmente equivalente a
1030 \code{kill(-pidgrp, signal)}; il suo prototipo è:
1031 \begin{prototype}{signal.h}{int killpg(pid\_t pidgrp, int signal)}
1033 Invia il segnale \param{signal} al \itindex{process~group} \textit{process
1034 group} \param{pidgrp}.
1036 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
1037 errore, gli errori sono gli stessi di \func{kill}.}
1039 \noindent e permette di inviare un segnale a tutto un \itindex{process~group}
1040 \textit{process group} (vedi sez.~\ref{sec:sess_proc_group}).
1045 \begin{tabular}[c]{|r|l|}
1047 \textbf{Valore} & \textbf{Significato} \\
1050 $>0$ & Il segnale è mandato al processo con il \acr{pid} indicato.\\
1051 0 & Il segnale è mandato ad ogni processo del \itindex{process~group}
1052 \textit{process group} del chiamante.\\
1053 $-1$ & Il segnale è mandato ad ogni processo (eccetto \cmd{init}).\\
1054 $<-1$ & Il segnale è mandato ad ogni processo del \textit{process group}
1055 \itindex{process~group} $|\code{pid}|$.\\
1058 \caption{Valori dell'argomento \param{pid} per la funzione
1060 \label{tab:sig_kill_values}
1063 Solo l'amministratore può inviare un segnale ad un processo qualunque, in
1064 tutti gli altri casi l'user-ID reale o l'user-ID effettivo del processo
1065 chiamante devono corrispondere all'user-ID reale o all'user-ID salvato della
1066 destinazione. Fa eccezione il caso in cui il segnale inviato sia
1067 \const{SIGCONT}, nel quale occorre che entrambi i processi appartengano alla
1068 stessa sessione. Inoltre, dato il ruolo fondamentale che riveste nel sistema
1069 (si ricordi quanto visto in sez.~\ref{sec:sig_termination}), non è possibile
1070 inviare al processo 1 (cioè a \cmd{init}) segnali per i quali esso non abbia
1071 un gestore installato.
1073 Infine, seguendo le specifiche POSIX 1003.1-2001, l'uso della chiamata
1074 \code{kill(-1, sig)} comporta che il segnale sia inviato (con la solita
1075 eccezione di \cmd{init}) a tutti i processi per i quali i permessi lo
1076 consentano. Lo standard permette comunque alle varie implementazioni di
1077 escludere alcuni processi specifici: nel caso in questione Linux non invia il
1078 segnale al processo che ha effettuato la chiamata.
1081 \subsection{Le funzioni \func{alarm} e \func{abort}}
1082 \label{sec:sig_alarm_abort}
1084 Un caso particolare di segnali generati a richiesta è quello che riguarda i
1085 vari segnali di temporizzazione e \const{SIGABRT}, per ciascuno di questi
1086 segnali sono previste funzioni specifiche che ne effettuino l'invio. La più
1087 comune delle funzioni usate per la temporizzazione è \funcd{alarm} il cui
1089 \begin{prototype}{unistd.h}{unsigned int alarm(unsigned int seconds)}
1090 Predispone l'invio di \const{SIGALRM} dopo \param{seconds} secondi.
1092 \bodydesc{La funzione restituisce il numero di secondi rimanenti ad un
1093 precedente allarme, o zero se non c'erano allarmi pendenti.}
1096 La funzione fornisce un meccanismo che consente ad un processo di predisporre
1097 un'interruzione nel futuro, (ad esempio per effettuare una qualche operazione
1098 dopo un certo periodo di tempo), programmando l'emissione di un segnale (nel
1099 caso in questione \const{SIGALRM}) dopo il numero di secondi specificato da
1102 Se si specifica per \param{seconds} un valore nullo non verrà inviato nessun
1103 segnale; siccome alla chiamata viene cancellato ogni precedente allarme,
1104 questo può essere usato per cancellare una programmazione precedente.
1106 La funzione inoltre ritorna il numero di secondi rimanenti all'invio
1107 dell'allarme programmato in precedenza. In questo modo è possibile controllare
1108 se non si è cancellato un precedente allarme e predisporre eventuali misure
1109 che permettano di gestire il caso in cui servono più interruzioni.
1111 In sez.~\ref{sec:sys_unix_time} abbiamo visto che ad ogni processo sono
1112 associati tre tempi diversi: il \textit{clock time}, l'\textit{user time} ed
1113 il \textit{system time}. Per poterli calcolare il kernel mantiene per ciascun
1114 processo tre diversi timer:
1116 \item un \textit{real-time timer} che calcola il tempo reale trascorso (che
1117 corrisponde al \textit{clock time}). La scadenza di questo timer provoca
1118 l'emissione di \const{SIGALRM};
1119 \item un \textit{virtual timer} che calcola il tempo di processore usato dal
1120 processo in user space (che corrisponde all'\textit{user time}). La scadenza
1121 di questo timer provoca l'emissione di \const{SIGVTALRM};
1122 \item un \textit{profiling timer} che calcola la somma dei tempi di processore
1123 utilizzati direttamente dal processo in user space, e dal kernel nelle
1124 system call ad esso relative (che corrisponde a quello che in
1125 sez.~\ref{sec:sys_unix_time} abbiamo chiamato \textit{CPU time}). La scadenza
1126 di questo timer provoca l'emissione di \const{SIGPROF}.
1129 Il timer usato da \func{alarm} è il \textit{clock time}, e corrisponde cioè al
1130 tempo reale. La funzione come abbiamo visto è molto semplice, ma proprio per
1131 questo presenta numerosi limiti: non consente di usare gli altri timer, non
1132 può specificare intervalli di tempo con precisione maggiore del secondo e
1133 genera il segnale una sola volta.
1135 Per ovviare a questi limiti Linux deriva da BSD la funzione \funcd{setitimer}
1136 che permette di usare un timer qualunque e l'invio di segnali periodici, al
1137 costo però di una maggiore complessità d'uso e di una minore portabilità. Il
1139 \begin{prototype}{sys/time.h}{int setitimer(int which, const struct
1140 itimerval *value, struct itimerval *ovalue)}
1142 Predispone l'invio di un segnale di allarme alla scadenza dell'intervallo
1143 \param{value} sul timer specificato da \param{which}.
1145 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
1146 errore, nel qual caso \var{errno} assumerà uno dei valori \errval{EINVAL} o
1150 Il valore di \param{which} permette di specificare quale dei tre timer
1151 illustrati in precedenza usare; i possibili valori sono riportati in
1152 tab.~\ref{tab:sig_setitimer_values}.
1156 \begin{tabular}[c]{|l|l|}
1158 \textbf{Valore} & \textbf{Timer} \\
1161 \const{ITIMER\_REAL} & \textit{real-time timer}\\
1162 \const{ITIMER\_VIRTUAL} & \textit{virtual timer}\\
1163 \const{ITIMER\_PROF} & \textit{profiling timer}\\
1166 \caption{Valori dell'argomento \param{which} per la funzione
1168 \label{tab:sig_setitimer_values}
1171 Il valore della struttura specificata \param{value} viene usato per impostare
1172 il timer, se il puntatore \param{ovalue} non è nullo il precedente valore
1173 viene salvato qui. I valori dei timer devono essere indicati attraverso una
1174 struttura \struct{itimerval}, definita in fig.~\ref{fig:file_stat_struct}.
1176 La struttura è composta da due membri, il primo, \var{it\_interval} definisce
1177 il periodo del timer; il secondo, \var{it\_value} il tempo mancante alla
1178 scadenza. Entrambi esprimono i tempi tramite una struttura \struct{timeval} che
1179 permette una precisione fino al microsecondo.
1181 Ciascun timer decrementa il valore di \var{it\_value} fino a zero, poi invia
1182 il segnale e reimposta \var{it\_value} al valore di \var{it\_interval}, in
1183 questo modo il ciclo verrà ripetuto; se invece il valore di \var{it\_interval}
1184 è nullo il timer si ferma.
1186 \begin{figure}[!htb]
1187 \footnotesize \centering
1188 \begin{minipage}[c]{15cm}
1189 \includestruct{listati/itimerval.h}
1192 \caption{La struttura \structd{itimerval}, che definisce i valori dei timer
1194 \label{fig:sig_itimerval}
1197 L'uso di \func{setitimer} consente dunque un controllo completo di tutte le
1198 caratteristiche dei timer, ed in effetti la stessa \func{alarm}, benché
1199 definita direttamente nello standard POSIX.1, può a sua volta essere espressa
1200 in termini di \func{setitimer}, come evidenziato dal manuale delle \acr{glibc}
1201 \cite{glibc} che ne riporta la definizione mostrata in
1202 fig.~\ref{fig:sig_alarm_def}.\footnote{questo comporta anche che non è il caso
1203 di mescolare chiamate ad \func{abort} e a \func{setitimer}.}
1205 \begin{figure}[!htb]
1206 \footnotesize \centering
1207 \begin{minipage}[c]{15cm}
1208 \includestruct{listati/alarm_def.c}
1211 \caption{Definizione di \func{alarm} in termini di \func{setitimer}.}
1212 \label{fig:sig_alarm_def}
1215 Si deve comunque tenere presente che fino al kernel 2.6.16 la precisione di
1216 queste funzioni era limitata dalla frequenza del timer di sistema,\footnote{il
1217 valore della constante \texttt{HZ}, di cui abbiamo già parlato in
1218 sez.~\ref{sec:proc_hierarchy}.} in quanto le temporizzazioni erano calcolate
1219 in numero di interruzioni del timer (i cosiddetti ''\textit{jiffies}''), ed era
1220 assicurato soltanto che il segnale non sarebbe stato mai generato prima della
1221 scadenza programmata (l'arrotondamento cioè era effettuato per
1222 eccesso).\footnote{questo in realtà non è del tutto vero a causa di un bug,
1223 presente fino al kernel 2.6.12, che in certe circostanze causava l'emissione
1224 del segnale con un arrotondamento per difetto.} L'uso del contatore dei
1225 \textit{jiffies}, un intero a 32 bit, comportava inoltre l'impossibilità di
1226 specificare tempi molto lunghi.\footnote{superiori al valore della costante
1227 \const{MAX\_SEC\_IN\_JIFFIES}, pari, nel caso di default di un valore di
1228 \const{HZ} di 250, a circa 99 giorni e mezzo.} Con il cambiamento della
1229 rappresentazione effettuato nel kernel 2.6.16 questo problema è scomparso e
1230 con l'introduzione dei timer ad alta risoluzione (vedi
1231 sez.~\ref{sec:sig_timer_adv}) nel kernel 2.6.21 la precisione è diventata
1232 quella fornita dall'hardware disponibile.
1234 Una seconda causa di potenziali ritardi è che il segnale viene generato alla
1235 scadenza del timer, ma poi deve essere consegnato al processo; se quest'ultimo
1236 è attivo (questo è sempre vero per \const{ITIMER\_VIRT}) la consegna è
1237 immediata, altrimenti può esserci un ulteriore ritardo che può variare a
1238 seconda del carico del sistema.
1240 Questo ha una conseguenza che può indurre ad errori molto subdoli, si tenga
1241 conto poi che in caso di sistema molto carico, si può avere il caso patologico
1242 in cui un timer scade prima che il segnale di una precedente scadenza sia
1243 stato consegnato; in questo caso, per il comportamento dei segnali descritto
1244 in sez.~\ref{sec:sig_sigchld}, un solo segnale sarà consegnato.
1246 Dato che sia \func{alarm} che \func{setitimer} non consentono di leggere il
1247 valore corrente di un timer senza modificarlo, è possibile usare la funzione
1248 \funcd{getitimer}, il cui prototipo è:
1249 \begin{prototype}{sys/time.h}{int getitimer(int which, struct
1252 Legge in \param{value} il valore del timer specificato da \param{which}.
1254 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
1255 errore e restituisce gli stessi errori di \func{getitimer}}
1257 \noindent i cui argomenti hanno lo stesso significato e formato di quelli di
1261 L'ultima funzione che permette l'invio diretto di un segnale è \funcd{abort},
1262 che, come accennato in sez.~\ref{sec:proc_termination}, permette di abortire
1263 l'esecuzione di un programma tramite l'invio di \const{SIGABRT}. Il suo
1265 \begin{prototype}{stdlib.h}{void abort(void)}
1267 Abortisce il processo corrente.
1269 \bodydesc{La funzione non ritorna, il processo è terminato inviando il
1270 segnale di \const{SIGABRT}.}
1273 La differenza fra questa funzione e l'uso di \func{raise} è che anche se il
1274 segnale è bloccato o ignorato, la funzione ha effetto lo stesso. Il segnale
1275 può però essere intercettato per effettuare eventuali operazioni di chiusura
1276 prima della terminazione del processo.
1278 Lo standard ANSI C richiede inoltre che anche se il gestore ritorna, la
1279 funzione non ritorni comunque. Lo standard POSIX.1 va oltre e richiede che se
1280 il processo non viene terminato direttamente dal gestore sia la stessa
1281 \func{abort} a farlo al ritorno dello stesso. Inoltre, sempre seguendo lo
1282 standard POSIX, prima della terminazione tutti i file aperti e gli stream
1283 saranno chiusi ed i buffer scaricati su disco. Non verranno invece eseguite le
1284 eventuali funzioni registrate con \func{atexit} e \func{on\_exit}.
1287 \subsection{Le funzioni di pausa e attesa}
1288 \label{sec:sig_pause_sleep}
1290 Sono parecchie le occasioni in cui si può avere necessità di sospendere
1291 temporaneamente l'esecuzione di un processo. Nei sistemi più elementari in
1292 genere questo veniva fatto con un opportuno loop di attesa, ma in un sistema
1293 multitasking un loop di attesa è solo un inutile spreco di CPU, per questo ci
1294 sono apposite funzioni che permettono di mettere un processo in stato di
1295 attesa.\footnote{si tratta in sostanza di funzioni che permettono di portare
1296 esplicitamente il processo in stato di \textit{sleep}, vedi
1297 sez.~\ref{sec:proc_sched}.}
1299 Il metodo tradizionale per fare attendere ad un processo fino all'arrivo di un
1300 segnale è quello di usare la funzione \funcd{pause}, il cui prototipo è:
1301 \begin{prototype}{unistd.h}{int pause(void)}
1303 Pone il processo in stato di sleep fino al ritorno di un gestore.
1305 \bodydesc{La funzione ritorna solo dopo che un segnale è stato ricevuto ed
1306 il relativo gestore è ritornato, nel qual caso restituisce $-1$ e
1307 \var{errno} assumerà il valore \errval{EINTR}.}
1310 La funzione segnala sempre una condizione di errore (il successo sarebbe
1311 quello di aspettare indefinitamente). In genere si usa questa funzione quando
1312 si vuole mettere un processo in attesa di un qualche evento specifico che non
1313 è sotto il suo diretto controllo (ad esempio la si può usare per interrompere
1314 l'esecuzione del processo fino all'arrivo di un segnale inviato da un altro
1317 Quando invece si vuole fare attendere un processo per un intervallo di tempo
1318 già noto nello standard POSIX.1 viene definita la funzione \funcd{sleep}, il
1320 \begin{prototype}{unistd.h}{unsigned int sleep(unsigned int seconds)}
1322 Pone il processo in stato di sleep per \param{seconds} secondi.
1324 \bodydesc{La funzione restituisce zero se l'attesa viene completata, o il
1325 numero di secondi restanti se viene interrotta da un segnale.}
1328 La funzione attende per il tempo specificato, a meno di non essere interrotta
1329 da un segnale. In questo caso non è una buona idea ripetere la chiamata per il
1330 tempo rimanente, in quanto la riattivazione del processo può avvenire in un
1331 qualunque momento, ma il valore restituito sarà sempre arrotondato al secondo,
1332 con la conseguenza che, se la successione dei segnali è particolarmente
1333 sfortunata e le differenze si accumulano, si potranno avere ritardi anche di
1334 parecchi secondi. In genere la scelta più sicura è quella di stabilire un
1335 termine per l'attesa, e ricalcolare tutte le volte il numero di secondi da
1338 In alcune implementazioni inoltre l'uso di \func{sleep} può avere conflitti
1339 con quello di \const{SIGALRM}, dato che la funzione può essere realizzata con
1340 l'uso di \func{pause} e \func{alarm} (in maniera analoga all'esempio che
1341 vedremo in sez.~\ref{sec:sig_example}). In tal caso mescolare chiamata di
1342 \func{alarm} e \func{sleep} o modificare l'azione di \const{SIGALRM}, può
1343 causare risultati indefiniti. Nel caso delle \acr{glibc} è stata usata una
1344 implementazione completamente indipendente e questi problemi non ci sono.
1346 La granularità di \func{sleep} permette di specificare attese soltanto in
1347 secondi, per questo sia sotto BSD4.3 che in SUSv2 è stata definita la funzione
1348 \funcd{usleep} (dove la \texttt{u} è intesa come sostituzione di $\mu$); i due
1349 standard hanno delle definizioni diverse, ma le \acr{glibc}
1350 seguono\footnote{secondo la pagina di manuale almeno dalla versione 2.2.2.}
1351 seguono quella di SUSv2 che prevede il seguente prototipo:
1352 \begin{prototype}{unistd.h}{int usleep(unsigned long usec)}
1354 Pone il processo in stato di sleep per \param{usec} microsecondi.
1356 \bodydesc{La funzione restituisce zero se l'attesa viene completata, o $-1$
1357 in caso di errore, nel qual caso \var{errno} assumerà il valore
1362 Anche questa funzione, a seconda delle implementazioni, può presentare
1363 problemi nell'interazione con \func{alarm} e \const{SIGALRM}. È pertanto
1364 deprecata in favore della funzione \funcd{nanosleep}, definita dallo standard
1365 POSIX1.b, il cui prototipo è:
1366 \begin{prototype}{unistd.h}{int nanosleep(const struct timespec *req, struct
1369 Pone il processo in stato di sleep per il tempo specificato da \param{req}.
1370 In caso di interruzione restituisce il tempo restante in \param{rem}.
1372 \bodydesc{La funzione restituisce zero se l'attesa viene completata, o $-1$
1373 in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
1375 \item[\errcode{EINVAL}] si è specificato un numero di secondi negativo o un
1376 numero di nanosecondi maggiore di 999.999.999.
1377 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
1381 Lo standard richiede che la funzione sia implementata in maniera del tutto
1382 indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto
1383 utilizzando direttamente il timer del kernel.} e sia utilizzabile senza
1384 interferenze con l'uso di \const{SIGALRM}. La funzione prende come argomenti
1385 delle strutture di tipo \struct{timespec}, la cui definizione è riportata in
1386 fig.~\ref{fig:sys_timespec_struct}, che permette di specificare un tempo con
1387 una precisione fino al nanosecondo.
1389 La funzione risolve anche il problema di proseguire l'attesa dopo
1390 l'interruzione dovuta ad un segnale; infatti in tal caso in \param{rem} viene
1391 restituito il tempo rimanente rispetto a quanto richiesto
1392 inizialmente,\footnote{con l'eccezione, valida solo nei kernel della serie
1393 2.4, in cui, per i processi riavviati dopo essere stati fermati da un
1394 segnale, il tempo passato in stato \texttt{T} non viene considerato nel
1395 calcolo della rimanenza.} e basta richiamare la funzione per completare
1396 l'attesa.\footnote{anche qui però occorre tenere presente che i tempi sono
1397 arrotondati, per cui la precisione, per quanto migliore di quella ottenibile
1398 con \func{sleep}, è relativa e in caso di molte interruzioni si può avere
1399 una deriva, per questo esiste la funzione \func{clock\_nanosleep} (vedi
1400 sez.~\ref{sec:sig_timer_adv}) che permette di specificare un tempo assoluto
1401 anziché un tempo relativo.}
1403 Chiaramente, anche se il tempo può essere specificato con risoluzioni fino al
1404 nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
1405 temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
1406 specificato, ma prima che il processo possa tornare ad essere eseguito
1407 occorrerà almeno attendere la successiva interruzione del timer di sistema,
1408 cioè un tempo che a seconda dei casi può arrivare fino a 1/\const{HZ}, (sempre
1409 che il sistema sia scarico ed il processa venga immediatamente rimesso in
1410 esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
1411 arrotondato al multiplo successivo di 1/\const{HZ}.
1413 Con i kernel della serie 2.4 in realtà era possibile ottenere anche pause più
1414 precise del centesimo di secondo usando politiche di \itindex{scheduler}
1415 scheduling \textit{real-time} come \const{SCHED\_FIFO} o \const{SCHED\_RR}; in
1416 tal caso infatti il calcolo sul numero di interruzioni del timer veniva
1417 evitato utilizzando direttamente un ciclo di attesa con cui si raggiungevano
1418 pause fino ai 2~ms con precisioni del $\mu$s. Questa estensione è stata
1419 rimossa con i kernel della serie 2.6, che consentono una risoluzione più alta
1420 del timer di sistema; inoltre a partire dal kernel 2.6.21, \func{nanosleep}
1421 può avvalersi del supporto dei timer ad alta risoluzione, ottenendo la massima
1422 precisione disponibile sull'hardware della propria macchina.
1425 \subsection{Un esempio elementare}
1426 \label{sec:sig_sigchld}
1428 Un semplice esempio per illustrare il funzionamento di un gestore di segnale è
1429 quello della gestione di \const{SIGCHLD}. Abbiamo visto in
1430 sez.~\ref{sec:proc_termination} che una delle azioni eseguite dal kernel alla
1431 conclusione di un processo è quella di inviare questo segnale al
1432 padre.\footnote{in realtà in SVr4 eredita la semantica di System V, in cui il
1433 segnale si chiama \const{SIGCLD} e viene trattato in maniera speciale; in
1434 System V infatti se si imposta esplicitamente l'azione a \const{SIG\_IGN} il
1435 segnale non viene generato ed il sistema non genera \index{zombie} zombie
1436 (lo stato di terminazione viene scartato senza dover chiamare una
1437 \func{wait}). L'azione predefinita è sempre quella di ignorare il segnale,
1438 ma non attiva questo comportamento. Linux, come BSD e POSIX, non supporta
1439 questa semantica ed usa il nome di \const{SIGCLD} come sinonimo di
1440 \const{SIGCHLD}.} In generale dunque, quando non interessa elaborare lo
1441 stato di uscita di un processo, si può completare la gestione della
1442 terminazione installando un gestore per \const{SIGCHLD} il cui unico compito
1443 sia quello di chiamare \func{waitpid} per completare la procedura di
1444 terminazione in modo da evitare la formazione di \index{zombie} zombie.
1446 In fig.~\ref{fig:sig_sigchld_handl} è mostrato il codice contenente una
1447 implementazione generica di una funzione di gestione per \const{SIGCHLD}, (che
1448 si trova nei sorgenti allegati nel file \file{SigHand.c}); se ripetiamo i test
1449 di sez.~\ref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione
1450 \cmd{-s} (che si limita ad effettuare l'installazione di questa funzione come
1451 gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione
1452 di \index{zombie} zombie.
1454 \begin{figure}[!htb]
1455 \footnotesize \centering
1456 \begin{minipage}[c]{15cm}
1457 \includecodesample{listati/hand_sigchild.c}
1460 \caption{Codice di una funzione generica di gestione per il segnale
1462 \label{fig:sig_sigchld_handl}
1465 Il codice del gestore è di lettura immediata; come buona norma di
1466 programmazione (si ricordi quanto accennato sez.~\ref{sec:sys_errno}) si
1467 comincia (\texttt{\small 6--7}) con il salvare lo stato corrente di
1468 \var{errno}, in modo da poterlo ripristinare prima del ritorno del gestore
1469 (\texttt{\small 16--17}). In questo modo si preserva il valore della variabile
1470 visto dal corso di esecuzione principale del processo, che altrimenti sarebbe
1471 sovrascritto dal valore restituito nella successiva chiamata di \func{waitpid}.
1473 Il compito principale del gestore è quello di ricevere lo stato di
1474 terminazione del processo, cosa che viene eseguita nel ciclo in
1475 (\texttt{\small 9--15}). Il ciclo è necessario a causa di una caratteristica
1476 fondamentale della gestione dei segnali: abbiamo già accennato come fra la
1477 generazione di un segnale e l'esecuzione del gestore possa passare un certo
1478 lasso di tempo e niente ci assicura che il gestore venga eseguito prima della
1479 generazione di ulteriori segnali dello stesso tipo. In questo caso normalmente
1480 i segnali successivi vengono ``\textsl{fusi}'' col primo ed al processo ne
1481 viene recapitato soltanto uno.
1483 Questo può essere un caso comune proprio con \const{SIGCHLD}, qualora capiti
1484 che molti processi figli terminino in rapida successione. Esso inoltre si
1485 presenta tutte le volte che un segnale viene bloccato: per quanti siano i
1486 segnali emessi durante il periodo di blocco, una volta che quest'ultimo sarà
1487 rimosso verrà recapitato un solo segnale.
1489 Allora, nel caso della terminazione dei processi figli, se si chiamasse
1490 \func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un
1491 solo processo, anche se i processi terminati sono più di uno, e gli altri
1492 resterebbero in stato di \index{zombie} zombie per un tempo indefinito.
1494 Per questo occorre ripetere la chiamata di \func{waitpid} fino a che essa non
1495 ritorni un valore nullo, segno che non resta nessun processo di cui si debba
1496 ancora ricevere lo stato di terminazione (si veda sez.~\ref{sec:proc_wait} per
1497 la sintassi della funzione). Si noti anche come la funzione venga invocata con
1498 il parametro \const{WNOHANG} che permette di evitare il suo blocco quando
1499 tutti gli stati di terminazione sono stati ricevuti.
1503 \section{La gestione avanzata dei segnali}
1504 \label{sec:sig_adv_control}
1506 Le funzioni esaminate finora fanno riferimento alle modalità più elementari
1507 della gestione dei segnali; non si sono pertanto ancora prese in
1508 considerazione le tematiche più complesse, collegate alle varie
1509 \itindex{race~condition} \textit{race condition} che i segnali possono
1510 generare e alla natura asincrona degli stessi.
1512 Affronteremo queste problematiche in questa sezione, partendo da un esempio
1513 che le evidenzi, per poi prendere in esame le varie funzioni che permettono di
1514 risolvere i problemi più complessi connessi alla programmazione con i segnali,
1515 fino a trattare le caratteristiche generali della gestione dei medesimi nella
1516 casistica ordinaria.
1519 \subsection{Alcune problematiche aperte}
1520 \label{sec:sig_example}
1522 Come accennato in sez.~\ref{sec:sig_pause_sleep} è possibile implementare
1523 \func{sleep} a partire dall'uso di \func{pause} e \func{alarm}. A prima vista
1524 questo può sembrare di implementazione immediata; ad esempio una semplice
1525 versione di \func{sleep} potrebbe essere quella illustrata in
1526 fig.~\ref{fig:sig_sleep_wrong}.
1528 \begin{figure}[!htb]
1529 \footnotesize \centering
1530 \begin{minipage}[c]{15cm}
1531 \includecodesample{listati/sleep_danger.c}
1534 \caption{Una implementazione pericolosa di \func{sleep}.}
1535 \label{fig:sig_sleep_wrong}
1538 Dato che è nostra intenzione utilizzare \const{SIGALRM} il primo passo della
1539 nostra implementazione sarà quello di installare il relativo gestore salvando
1540 il precedente (\texttt{\small 14-17}). Si effettuerà poi una chiamata ad
1541 \func{alarm} per specificare il tempo d'attesa per l'invio del segnale a cui
1542 segue la chiamata a \func{pause} per fermare il programma (\texttt{\small
1543 18-20}) fino alla sua ricezione. Al ritorno di \func{pause}, causato dal
1544 ritorno del gestore (\texttt{\small 1-9}), si ripristina il gestore originario
1545 (\texttt{\small 21-22}) restituendo l'eventuale tempo rimanente
1546 (\texttt{\small 23-24}) che potrà essere diverso da zero qualora
1547 l'interruzione di \func{pause} venisse causata da un altro segnale.
1549 Questo codice però, a parte il non gestire il caso in cui si è avuta una
1550 precedente chiamata a \func{alarm} (che si è tralasciato per brevità),
1551 presenta una pericolosa \itindex{race~condition} \textit{race condition}.
1552 Infatti, se il processo viene interrotto fra la chiamata di \func{alarm} e
1553 \func{pause}, può capitare (ad esempio se il sistema è molto carico) che il
1554 tempo di attesa scada prima dell'esecuzione di quest'ultima, cosicché essa
1555 sarebbe eseguita dopo l'arrivo di \const{SIGALRM}. In questo caso ci si
1556 troverebbe di fronte ad un \itindex{deadlock} deadlock, in quanto \func{pause}
1557 non verrebbe mai più interrotta (se non in caso di un altro segnale).
1559 Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
1560 SVr2) usando la funzione \func{longjmp} (vedi sez.~\ref{sec:proc_longjmp}) per
1561 uscire dal gestore; in questo modo, con una condizione sullo stato di
1562 uscita di quest'ultima, si può evitare la chiamata a \func{pause}, usando un
1563 codice del tipo di quello riportato in fig.~\ref{fig:sig_sleep_incomplete}.
1565 \begin{figure}[!htb]
1566 \footnotesize \centering
1567 \begin{minipage}[c]{15cm}
1568 \includecodesample{listati/sleep_defect.c}
1571 \caption{Una implementazione ancora malfunzionante di \func{sleep}.}
1572 \label{fig:sig_sleep_incomplete}
1575 In questo caso il gestore (\texttt{\small 18-27}) non ritorna come in
1576 fig.~\ref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 25}) per
1577 rientrare nel corpo principale del programma; dato che in questo caso il
1578 valore di uscita di \func{setjmp} è 1, grazie alla condizione in
1579 (\texttt{\small 9-12}) si evita comunque che \func{pause} sia chiamata a
1582 Ma anche questa implementazione comporta dei problemi; in questo caso infatti
1583 non viene gestita correttamente l'interazione con gli altri segnali; se
1584 infatti il segnale di allarme interrompe un altro gestore, l'esecuzione non
1585 riprenderà nel gestore in questione, ma nel ciclo principale, interrompendone
1586 inopportunamente l'esecuzione. Lo stesso tipo di problemi si presenterebbero
1587 se si volesse usare \func{alarm} per stabilire un timeout su una qualunque
1588 system call bloccante.
1590 Un secondo esempio è quello in cui si usa il segnale per notificare una
1591 qualche forma di evento; in genere quello che si fa in questo caso è impostare
1592 nel gestore un opportuno flag da controllare nel corpo principale del
1593 programma (con un codice del tipo di quello riportato in
1594 fig.~\ref{fig:sig_event_wrong}). La logica è quella di far impostare al
1595 gestore (\texttt{\small 14-19}) una variabile globale preventivamente
1596 inizializzata nel programma principale, il quale potrà determinare,
1597 osservandone il contenuto, l'occorrenza o meno del segnale, e prendere le
1598 relative azioni conseguenti (\texttt{\small 6-11}).
1600 \begin{figure}[!htb]
1601 \footnotesize\centering
1602 \begin{minipage}[c]{15cm}
1603 \includecodesample{listati/sig_alarm.c}
1606 \caption{Un esempio non funzionante del codice per il controllo di un
1607 evento generato da un segnale.}
1608 \label{fig:sig_event_wrong}
1611 Questo è il tipico esempio di caso, già citato in
1612 sez.~\ref{sec:proc_race_cond}, in cui si genera una \itindex{race~condition}
1613 \textit{race condition}; infatti, in una situazione in cui un segnale è già
1614 arrivato (e \var{flag} è già ad 1) se un altro segnale arriva immediatamente
1615 dopo l'esecuzione del controllo (\texttt{\small 6}) ma prima della
1616 cancellazione del flag (\texttt{\small 7}), la sua occorrenza sarà perduta.
1618 Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono
1619 delle funzioni più sofisticate di quelle finora illustrate, queste hanno la
1620 loro origine nella semplice interfaccia dei primi sistemi Unix, ma con esse
1621 non è possibile gestire in maniera adeguata di tutti i possibili aspetti con
1622 cui un processo deve reagire alla ricezione di un segnale.
1626 \subsection{Gli \textsl{insiemi di segnali} o \textit{signal set}}
1627 \label{sec:sig_sigset}
1629 \itindbeg{signal~set}
1631 Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali
1632 originarie, nate con la semantica inaffidabile, hanno dei limiti non
1633 superabili; in particolare non è prevista nessuna funzione che permetta di
1634 gestire il blocco dei segnali o di verificare lo stato dei segnali pendenti.
1635 Per questo motivo lo standard POSIX.1, insieme alla nuova semantica dei
1636 segnali ha introdotto una interfaccia di gestione completamente nuova, che
1637 permette di ottenere un controllo molto più dettagliato. In particolare lo
1638 standard ha introdotto un nuovo tipo di dato \type{sigset\_t}, che permette di
1639 rappresentare un \textsl{insieme di segnali} (un \textit{signal set}, come
1640 viene usualmente chiamato), tale tipo di dato viene usato per gestire il
1643 In genere un \textsl{insieme di segnali} è rappresentato da un intero di
1644 dimensione opportuna, di solito pari al numero di bit dell'architettura della
1645 macchina,\footnote{nel caso dei PC questo comporta un massimo di 32 segnali
1646 distinti: dato che in Linux questi sono sufficienti non c'è necessità di
1647 nessuna struttura più complicata.} ciascun bit del quale è associato ad uno
1648 specifico segnale; in questo modo è di solito possibile implementare le
1649 operazioni direttamente con istruzioni elementari del processore. Lo standard
1650 POSIX.1 definisce cinque funzioni per la manipolazione degli insiemi di
1651 segnali: \funcd{sigemptyset}, \funcd{sigfillset}, \funcd{sigaddset},
1652 \funcd{sigdelset} e \funcd{sigismember}, i cui prototipi sono:
1656 \funcdecl{int sigemptyset(sigset\_t *set)} Inizializza un insieme di segnali
1657 vuoto (in cui non c'è nessun segnale).
1659 \funcdecl{int sigfillset(sigset\_t *set)} Inizializza un insieme di segnali
1660 pieno (in cui ci sono tutti i segnali).
1662 \funcdecl{int sigaddset(sigset\_t *set, int signum)} Aggiunge il segnale
1663 \param{signum} all'insieme di segnali \param{set}.
1665 \funcdecl{int sigdelset(sigset\_t *set, int signum)} Toglie il segnale
1666 \param{signum} dall'insieme di segnali \param{set}.
1668 \funcdecl{int sigismember(const sigset\_t *set, int signum)} Controlla se il
1669 segnale \param{signum} è nell'insieme di segnali \param{set}.
1671 \bodydesc{Le prime quattro funzioni ritornano 0 in caso di successo, mentre
1672 \func{sigismember} ritorna 1 se \param{signum} è in \param{set} e 0
1673 altrimenti. In caso di errore tutte ritornano $-1$, con \var{errno}
1674 impostata a \errval{EINVAL} (il solo errore possibile è che \param{signum}
1675 non sia un segnale valido).}
1678 Dato che in generale non si può fare conto sulle caratteristiche di una
1679 implementazione (non è detto che si disponga di un numero di bit sufficienti
1680 per mettere tutti i segnali in un intero, o in \type{sigset\_t} possono essere
1681 immagazzinate ulteriori informazioni) tutte le operazioni devono essere
1682 comunque eseguite attraverso queste funzioni.
1684 In genere si usa un insieme di segnali per specificare quali segnali si vuole
1685 bloccare, o per riottenere dalle varie funzioni di gestione la maschera dei
1686 segnali attivi (vedi sez.~\ref{sec:sig_sigmask}). Essi possono essere definiti
1687 in due diverse maniere, aggiungendo i segnali voluti ad un insieme vuoto
1688 ottenuto con \func{sigemptyset} o togliendo quelli che non servono da un
1689 insieme completo ottenuto con \func{sigfillset}. Infine \func{sigismember}
1690 permette di verificare la presenza di uno specifico segnale in un
1693 \itindend{signal~set}
1696 \subsection{La funzione \func{sigaction}}
1697 \label{sec:sig_sigaction}
1699 Abbiamo già accennato in sez.~\ref{sec:sig_signal} i problemi di compatibilità
1700 relativi all'uso di \func{signal}. Per ovviare a tutto questo lo standard
1701 POSIX.1 ha ridefinito completamente l'interfaccia per la gestione dei segnali,
1702 rendendola molto più flessibile e robusta, anche se leggermente più complessa.
1704 La funzione principale dell'interfaccia POSIX.1 per i segnali è
1705 \funcd{sigaction}. Essa ha sostanzialmente lo stesso uso di \func{signal},
1706 permette cioè di specificare le modalità con cui un segnale può essere gestito
1707 da un processo. Il suo prototipo è:
1708 \begin{prototype}{signal.h}{int sigaction(int signum, const struct sigaction
1709 *act, struct sigaction *oldact)}
1711 Installa una nuova azione per il segnale \param{signum}.
1713 \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
1714 errore, nel qual caso \var{errno} assumerà i valori:
1716 \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido o si è
1717 cercato di installare il gestore per \const{SIGKILL} o
1719 \item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
1723 La funzione serve ad installare una nuova \textsl{azione} per il segnale
1724 \param{signum}; si parla di \textsl{azione} e non di \textsl{gestore}
1725 come nel caso di \func{signal}, in quanto la funzione consente di specificare
1726 le varie caratteristiche della risposta al segnale, non solo la funzione che
1727 verrà eseguita alla sua occorrenza. Per questo lo standard raccomanda di
1728 usare sempre questa funzione al posto di \func{signal} (che in genere viene
1729 definita tramite essa), in quanto permette un controllo completo su tutti gli
1730 aspetti della gestione di un segnale, sia pure al prezzo di una maggiore
1733 Se il puntatore \param{act} non è nullo, la funzione installa la nuova azione
1734 da esso specificata, se \param{oldact} non è nullo il valore dell'azione
1735 corrente viene restituito indietro. Questo permette (specificando \param{act}
1736 nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
1737 che non consente di ottenere l'azione corrente senza installarne una nuova.
1739 Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
1740 tramite la quale si specificano tutte le caratteristiche dell'azione associata
1741 ad un segnale. Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
1742 definita secondo quanto riportato in fig.~\ref{fig:sig_sigaction}. Il campo
1743 \var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
1746 \begin{figure}[!htb]
1747 \footnotesize \centering
1748 \begin{minipage}[c]{15cm}
1749 \includestruct{listati/sigaction.h}
1752 \caption{La struttura \structd{sigaction}.}
1753 \label{fig:sig_sigaction}
1756 Il campo \var{sa\_mask} serve ad indicare l'insieme dei segnali che devono
1757 essere bloccati durante l'esecuzione del gestore, ad essi viene comunque
1758 sempre aggiunto il segnale che ne ha causato la chiamata, a meno che non si
1759 sia specificato con \var{sa\_flag} un comportamento diverso. Quando il
1760 gestore ritorna comunque la maschera dei segnali bloccati (vedi
1761 sez.~\ref{sec:sig_sigmask}) viene ripristinata al valore precedente
1764 L'uso di questo campo permette ad esempio di risolvere il problema residuo
1765 dell'implementazione di \code{sleep} mostrata in
1766 fig.~\ref{fig:sig_sleep_incomplete}. In quel caso infatti se il segnale di
1767 allarme avesse interrotto un altro gestore questo non sarebbe stato eseguito
1768 correttamente; la cosa poteva essere prevenuta installando gli altri gestori
1769 usando \var{sa\_mask} per bloccare \const{SIGALRM} durante la loro esecuzione.
1770 Il valore di \var{sa\_flag} permette di specificare vari aspetti del
1771 comportamento di \func{sigaction}, e della reazione del processo ai vari
1772 segnali; i valori possibili ed il relativo significato sono riportati in
1773 tab.~\ref{tab:sig_sa_flag}.
1778 \begin{tabular}[c]{|l|p{8cm}|}
1780 \textbf{Valore} & \textbf{Significato} \\
1783 \const{SA\_NOCLDSTOP}& Se il segnale è \const{SIGCHLD} allora non deve
1784 essere notificato quando il processo figlio viene
1785 fermato da uno dei segnali \const{SIGSTOP},
1786 \const{SIGTSTP}, \const{SIGTTIN} o
1788 \const{SA\_RESETHAND}& Ristabilisce l'azione per il segnale al valore
1789 predefinito una volta che il gestore è stato
1790 lanciato, riproduce cioè il comportamento della
1791 semantica inaffidabile.\\
1792 \const{SA\_ONESHOT} & Nome obsoleto, sinonimo non standard di
1793 \const{SA\_RESETHAND}; da evitare.\\
1794 \const{SA\_ONSTACK} & Stabilisce l'uso di uno \itindex{stack}
1795 \textit{stack} alternativo per l'esecuzione del
1797 sez.~\ref{sec:sig_specific_features}).\\
1798 \const{SA\_RESTART} & Riavvia automaticamente le \textit{slow system
1799 call} quando vengono interrotte dal suddetto
1800 segnale; riproduce cioè il comportamento standard
1801 di BSD.\index{system~call~lente}\\
1802 \const{SA\_NODEFER} & Evita che il segnale corrente sia bloccato durante
1803 l'esecuzione del gestore.\\
1804 \const{SA\_NOMASK} & Nome obsoleto, sinonimo non standard di
1805 \const{SA\_NODEFER}.\\
1806 \const{SA\_SIGINFO} & Deve essere specificato quando si vuole usare un
1807 gestore in forma estesa usando
1808 \var{sa\_sigaction} al posto di
1809 \var{sa\_handler}.\\
1810 \const{SA\_NOCLDWAIT}& Se il segnale è \const{SIGCHLD} allora i processi
1811 figli non diventano \textit{zombie} quando
1812 terminano.\footnotemark \\
1815 \caption{Valori del campo \var{sa\_flag} della struttura \struct{sigaction}.}
1816 \label{tab:sig_sa_flag}
1819 \footnotetext{questa funzionalità è stata introdotta nel kernel 2.6 e va a
1820 modificare il comportamento di \func{waitpid}.}
1822 Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette
1823 di utilizzare due forme diverse di gestore,\footnote{la possibilità è prevista
1824 dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x
1825 con l'introduzione dei segnali real-time (vedi
1826 sez.~\ref{sec:sig_real_time}); in precedenza era possibile ottenere alcune
1827 informazioni addizionali usando \var{sa\_handler} con un secondo parametro
1828 addizionale di tipo \var{sigcontext}, che adesso è deprecato.} da
1829 specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO},
1830 rispettivamente attraverso i campi \var{sa\_sigaction} o
1831 \var{sa\_handler},\footnote{i due campi devono essere usati in maniera
1832 alternativa, in certe implementazioni questi campi vengono addirittura
1833 definiti come \ctyp{union}.} Quest'ultima è quella classica usata anche con
1834 \func{signal}, mentre la prima permette di usare un gestore più complesso, in
1835 grado di ricevere informazioni più dettagliate dal sistema, attraverso la
1836 struttura \struct{siginfo\_t}, riportata in fig.~\ref{fig:sig_siginfo_t}.
1838 Installando un gestore di tipo \var{sa\_sigaction} diventa allora possibile
1839 accedere alle informazioni restituite attraverso il puntatore a questa
1840 struttura. Tutti i segnali impostano i campi \var{si\_signo}, che riporta il
1841 numero del segnale ricevuto, \var{si\_errno}, che riporta, quando diverso da
1842 zero, il codice dell'errore associato al segnale, e \var{si\_code}, che viene
1843 usato dal kernel per specificare maggiori dettagli riguardo l'evento che ha
1844 causato l'emissione del segnale.
1846 \begin{figure}[!htb]
1847 \footnotesize \centering
1848 \begin{minipage}[c]{15cm}
1849 \includestruct{listati/siginfo_t.h}
1852 \caption{La struttura \structd{siginfo\_t}.}
1853 \label{fig:sig_siginfo_t}
1856 In generale \var{si\_code} contiene, per i segnali generici, per quelli
1857 real-time e per tutti quelli inviati tramite da un processo con \func{kill} o
1858 affini, le informazioni circa l'origine del segnale stesso, ad esempio se
1859 generato dal kernel, da un timer, da \func{kill}, ecc. Il valore viene sempre
1860 espresso come una costante,\footnote{le definizioni di tutti i valori
1861 possibili si trovano in \file{bits/siginfo.h}.} ed i valori possibili in
1862 questo caso sono riportati in tab.~\ref{tab:sig_sa_code_generic}.
1864 Nel caso di alcuni segnali però il valore di \var{si\_code} viene usato per
1865 fornire una informazione specifica relativa alle motivazioni della ricezione
1866 dello stesso; ad esempio i vari segnali di errore (\const{SIGILL},
1867 \const{SIGFPE}, \const{SIGSEGV} e \const{SIGBUS}) lo usano per fornire
1868 maggiori dettagli riguardo l'errore, come il tipo di errore aritmetico, di
1869 istruzione illecita o di violazione di memoria; mentre alcuni segnali di
1870 controllo (\const{SIGCHLD}, \const{SIGTRAP} e \const{SIGPOLL}) forniscono
1871 altre informazioni specifiche.
1876 \begin{tabular}[c]{|l|p{8cm}|}
1878 \textbf{Valore} & \textbf{Significato} \\
1881 \const{SI\_USER} & generato da \func{kill} o \func{raise}.\\
1882 \const{SI\_KERNEL} & inviato dal kernel.\\
1883 \const{SI\_QUEUE} & inviato con \func{sigqueue} (vedi
1884 sez.~\ref{sec:sig_real_time}).\\
1885 \const{SI\_TIMER} & scadenza di un POSIX timer
1886 (vedi sez.~\ref{sec:sig_timer_adv}).\\
1887 \const{SI\_MESGQ} & inviato al cambiamento di stato di una coda di
1888 messaggi POSIX (vedi
1889 sez.~\ref{sec:ipc_posix_mq}).\footnotemark\\
1890 \const{SI\_ASYNCIO}& una operazione di I/O asincrono (vedi
1891 sez.~\ref{sec:file_asyncronous_access}) è stata
1893 \const{SI\_SIGIO} & segnale di \const{SIGIO} da una coda (vedi
1894 sez.~\ref{sec:file_asyncronous_operation}).\\
1895 \const{SI\_TKILL} & inviato da \func{tkill} o \func{tgkill} (vedi
1896 sez.~\ref{cha:threads_xxx}).\footnotemark\\
1899 \caption{Valori del campo \var{sa\_code} della struttura \struct{sigaction}
1900 per i segnali generici.}
1901 \label{tab:sig_sa_code_generic}
1904 \footnotetext[24]{introdotto con il kernel 2.6.6.}
1905 \footnotetext{introdotto con il kernel 2.4.19.}
1907 In questo caso il valore del campo \var{si\_code} deve essere verificato nei
1908 confronti delle diverse costanti previste per ciascuno di detti
1909 segnali;\footnote{dato che si tratta di una costante, e non di una maschera
1910 binaria, i valori numerici vengono riutilizzati e ciascuno di essi avrà un
1911 significato diverso a seconda del segnale a cui è associato.} l'elenco
1912 dettagliato dei nomi di queste costanti è riportato nelle diverse sezioni di
1913 tab.~\ref{tab:sig_sa_code_special} che sono state ordinate nella sequenza in
1914 cui si sono appena citati i rispettivi segnali.\footnote{il prefisso del nome
1915 indica comunque in maniera diretta il segnale a cui le costanti fanno
1921 \begin{tabular}[c]{|l|p{8cm}|}
1923 \textbf{Valore} & \textbf{Significato} \\
1926 \const{ILL\_ILLOPC} & codice di operazione illegale.\\
1927 \const{ILL\_ILLOPN} & operando illegale.\\
1928 \const{ILL\_ILLADR} & modo di indirizzamento illegale.\\
1929 \const{ILL\_ILLTRP} & trappola di processore illegale.\\
1930 \const{ILL\_PRVOPC} & codice di operazione privilegiato.\\
1931 \const{ILL\_PRVREG} & registro privilegiato.\\
1932 \const{ILL\_COPROC} & errore del coprocessore.\\
1933 \const{ILL\_BADSTK} & errore nello stack interno.\\
1935 \const{FPE\_INTDIV} & divisione per zero intera.\\
1936 \const{FPE\_INTOVF} & overflow intero.\\
1937 \const{FPE\_FLTDIV} & divisione per zero in virgola mobile.\\
1938 \const{FPE\_FLTOVF} & overflow in virgola mobile.\\
1939 \const{FPE\_FLTUND} & underflow in virgola mobile.\\
1940 \const{FPE\_FLTRES} & risultato in virgola mobile non esatto.\\
1941 \const{FPE\_FLTINV} & operazione in virgola mobile non valida.\\
1942 \const{FPE\_FLTSUB} & mantissa? fuori intervallo.\\
1944 \const{SEGV\_MAPERR} & indirizzo non mappato.\\
1945 \const{SEGV\_ACCERR} & permessi non validi per l'indirizzo.\\
1947 \const{BUS\_ADRALN} & allineamento dell'indirizzo non valido.\\
1948 \const{BUS\_ADRERR} & indirizzo fisico inesistente.\\
1949 \const{BUS\_OBJERR} & errore hardware sull'indirizzo.\\
1951 \const{TRAP\_BRKPT} & breakpoint sul processo.\\
1952 \const{TRAP\_TRACE} & trappola di tracciamento del processo.\\
1954 \const{CLD\_EXITED} & il figlio è uscito.\\
1955 \const{CLD\_KILLED} & il figlio è stato terminato.\\
1956 \const{CLD\_DUMPED} & il figlio è terminato in modo anormale.\\
1957 \const{CLD\_TRAPPED} & un figlio tracciato ha raggiunto una trappola.\\
1958 \const{CLD\_STOPPED} & il figlio è stato fermato.\\
1959 \const{CLD\_CONTINUED}& il figlio è ripartito.\\
1961 \const{POLL\_IN} & disponibili dati in ingresso.\\
1962 \const{POLL\_OUT} & spazio disponibile sul buffer di uscita.\\
1963 \const{POLL\_MSG} & disponibili messaggi in ingresso.\\
1964 \const{POLL\_ERR} & errore di I/O.\\
1965 \const{POLL\_PRI} & disponibili dati di alta priorità in ingresso.\\
1966 \const{POLL\_HUP} & il dispositivo è stato disconnesso.\\
1969 \caption{Valori del campo \var{sa\_code} della struttura \struct{sigaction}
1970 impostati rispettivamente dai segnali \const{SIGILL}, \const{SIGFPE},
1971 \const{SIGSEGV}, \const{SIGBUS}, \const{SIGCHLD}, \const{SIGTRAP} e
1973 \label{tab:sig_sa_code_special}
1976 Il resto della struttura \struct{siginfo\_t} è definito come \ctyp{union} ed i
1977 valori eventualmente presenti dipendono dal segnale, così \const{SIGCHLD} ed i
1978 segnali real-time (vedi sez.~\ref{sec:sig_real_time}) inviati tramite
1979 \func{kill} avvalorano \var{si\_pid} e \var{si\_uid} coi valori corrispondenti
1980 al processo che ha emesso il segnale, \const{SIGCHLD} avvalora anche i campi
1981 \const{si\_status}, \const{si\_utime} e \const{si\_stime} che indicano
1982 rispettivamente lo stato di uscita, l'\textit{user time} e il \textit{system
1983 time} (vedi sez.~\ref{sec:sys_cpu_times}) usati dal processo;
1984 \const{SIGILL}, \const{SIGFPE}, \const{SIGSEGV} e \const{SIGBUS} avvalorano
1985 \var{si\_addr} con l'indirizzo in cui è avvenuto l'errore, \const{SIGIO} (vedi
1986 sez.~\ref{sec:file_asyncronous_io}) avvalora \var{si\_fd} con il numero del
1987 file descriptor e \var{si\_band} per i \itindex{out-of-band} dati urgenti
1988 (vedi sez.~\ref{sec:TCP_urgent_data}) su un socket.
1990 Benché sia possibile usare nello stesso programma sia \func{sigaction} che
1991 \func{signal} occorre molta attenzione, in quanto le due funzioni possono
1992 interagire in maniera anomala. Infatti l'azione specificata con
1993 \struct{sigaction} contiene un maggior numero di informazioni rispetto al
1994 semplice indirizzo del gestore restituito da \func{signal}. Per questo motivo
1995 se si usa quest'ultima per installare un gestore sostituendone uno
1996 precedentemente installato con \func{sigaction}, non sarà possibile effettuare
1997 un ripristino corretto dello stesso.
1999 Per questo è sempre opportuno usare \func{sigaction}, che è in grado di
2000 ripristinare correttamente un gestore precedente, anche se questo è stato
2001 installato con \func{signal}. In generale poi non è il caso di usare il valore
2002 di ritorno di \func{signal} come campo \var{sa\_handler}, o viceversa, dato
2003 che in certi sistemi questi possono essere diversi. In definitiva dunque, a
2004 meno che non si sia vincolati all'aderenza stretta allo standard ISO C, è
2005 sempre il caso di evitare l'uso di \func{signal} a favore di \func{sigaction}.
2007 \begin{figure}[!htb]
2008 \footnotesize \centering
2009 \begin{minipage}[c]{15.6cm}
2010 \includecodesample{listati/Signal.c}
2013 \caption{La funzione \func{Signal}, equivalente a \func{signal}, definita
2014 attraverso \func{sigaction}.}
2015 \label{fig:sig_Signal_code}
2018 Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
2019 che abbia le stesse caratteristiche di \func{signal}, a definire attraverso
2020 \func{sigaction} una funzione equivalente \func{Signal}, il cui codice è
2021 riportato in fig.~\ref{fig:sig_Signal_code} (il codice completo si trova nel
2022 file \file{SigHand.c} nei sorgenti allegati). Si noti come, essendo la
2023 funzione estremamente semplice, essa è definita come
2024 \direct{inline};\footnote{la direttiva \direct{inline} viene usata per dire al
2025 compilatore di trattare la funzione cui essa fa riferimento in maniera
2026 speciale inserendo il codice direttamente nel testo del programma. Anche se
2027 i compilatori più moderni sono in grado di effettuare da soli queste
2028 manipolazioni (impostando le opportune ottimizzazioni) questa è una tecnica
2029 usata per migliorare le prestazioni per le funzioni piccole ed usate di
2030 frequente (in particolare nel kernel, dove in certi casi le ottimizzazioni
2031 dal compilatore, tarate per l'uso in user space, non sono sempre adatte). In
2032 tal caso infatti le istruzioni per creare un nuovo frame nello
2033 \itindex{stack} \textit{stack} per chiamare la funzione costituirebbero una
2034 parte rilevante del codice, appesantendo inutilmente il programma.
2035 Originariamente questo comportamento veniva ottenuto con delle macro, ma
2036 queste hanno tutta una serie di problemi di sintassi nel passaggio degli
2037 argomenti (si veda ad esempio \cite{PratC}) che in questo modo possono
2038 essere evitati.} per semplificare ulteriormente la definizione si è poi
2039 definito un apposito tipo \texttt{SigFunc}.
2043 \subsection{La gestione della \textsl{maschera dei segnali} o
2044 \textit{signal mask}}
2045 \label{sec:sig_sigmask}
2047 \itindbeg{signal~mask}
2048 Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like
2049 permettono di bloccare temporaneamente (o di eliminare completamente,
2050 impostando \const{SIG\_IGN} come azione) la consegna dei segnali ad un
2051 processo. Questo è fatto specificando la cosiddetta \textsl{maschera dei
2052 segnali} (o \textit{signal mask}) del processo\footnote{nel caso di Linux
2053 essa è mantenuta dal campo \var{blocked} della \struct{task\_struct} del
2054 processo.} cioè l'insieme dei segnali la cui consegna è bloccata. Abbiamo
2055 accennato in sez.~\ref{sec:proc_fork} che la \textit{signal mask} viene
2056 ereditata dal padre alla creazione di un processo figlio, e abbiamo visto al
2057 paragrafo precedente che essa può essere modificata, durante l'esecuzione di
2058 un gestore, attraverso l'uso dal campo \var{sa\_mask} di \struct{sigaction}.
2060 Uno dei problemi evidenziatisi con l'esempio di fig.~\ref{fig:sig_event_wrong}
2061 è che in molti casi è necessario proteggere delle sezioni di codice (nel caso
2062 in questione la sezione fra il controllo e la eventuale cancellazione del flag
2063 che testimoniava l'avvenuta occorrenza del segnale) in modo da essere sicuri
2064 che essi siano eseguite senza interruzioni.
2066 Le operazioni più semplici, come l'assegnazione o il controllo di una
2067 variabile (per essere sicuri si può usare il tipo \type{sig\_atomic\_t}) di
2068 norma sono atomiche; quando si devono eseguire operazioni più complesse si può
2069 invece usare la funzione \funcd{sigprocmask} che permette di bloccare uno o
2070 più segnali; il suo prototipo è:
2071 \begin{prototype}{signal.h}
2072 {int sigprocmask(int how, const sigset\_t *set, sigset\_t *oldset)}
2074 Cambia la \textsl{maschera dei segnali} del processo corrente.
2076 \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
2077 errore, nel qual caso \var{errno} assumerà i valori:
2079 \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
2080 \item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
2084 La funzione usa l'insieme di segnali dato all'indirizzo \param{set} per
2085 modificare la maschera dei segnali del processo corrente. La modifica viene
2086 effettuata a seconda del valore dell'argomento \param{how}, secondo le modalità
2087 specificate in tab.~\ref{tab:sig_procmask_how}. Qualora si specifichi un valore
2088 non nullo per \param{oldset} la maschera dei segnali corrente viene salvata a
2094 \begin{tabular}[c]{|l|p{8cm}|}
2096 \textbf{Valore} & \textbf{Significato} \\
2099 \const{SIG\_BLOCK} & L'insieme dei segnali bloccati è l'unione fra
2100 quello specificato e quello corrente.\\
2101 \const{SIG\_UNBLOCK} & I segnali specificati in \param{set} sono rimossi
2102 dalla maschera dei segnali, specificare la
2103 cancellazione di un segnale non bloccato è legale.\\
2104 \const{SIG\_SETMASK} & La maschera dei segnali è impostata al valore
2105 specificato da \param{set}.\\
2108 \caption{Valori e significato dell'argomento \param{how} della funzione
2109 \func{sigprocmask}.}
2110 \label{tab:sig_procmask_how}
2113 In questo modo diventa possibile proteggere delle sezioni di codice bloccando
2114 l'insieme di segnali voluto per poi riabilitarli alla fine della
2115 \index{sezione~critica} sezione critica. La funzione permette di risolvere
2116 problemi come quelli mostrati in fig.~\ref{fig:sig_event_wrong}, proteggendo
2117 la sezione fra il controllo del flag e la sua cancellazione.
2119 La funzione può essere usata anche all'interno di un gestore, ad esempio
2120 per riabilitare la consegna del segnale che l'ha invocato, in questo caso però
2121 occorre ricordare che qualunque modifica alla maschera dei segnali viene
2122 perduta alla conclusione del terminatore.
2124 Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
2125 dei casi di \itindex{race~condition} \textit{race condition} restano aperte
2126 alcune possibilità legate all'uso di \func{pause}; il caso è simile a quello
2127 del problema illustrato nell'esempio di fig.~\ref{fig:sig_sleep_incomplete}, e
2128 cioè la possibilità che il processo riceva il segnale che si intende usare per
2129 uscire dallo stato di attesa invocato con \func{pause} immediatamente prima
2130 dell'esecuzione di quest'ultima. Per poter effettuare atomicamente la modifica
2131 della maschera dei segnali (di solito attivandone uno specifico) insieme alla
2132 sospensione del processo lo standard POSIX ha previsto la funzione
2133 \funcd{sigsuspend}, il cui prototipo è:
2134 \begin{prototype}{signal.h}
2135 {int sigsuspend(const sigset\_t *mask)}
2137 Imposta la \textit{signal mask} specificata, mettendo in attesa il processo.
2139 \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
2140 errore, nel qual caso \var{errno} assumerà i valori:
2142 \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
2143 \item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
2147 Come esempio dell'uso di queste funzioni proviamo a riscrivere un'altra volta
2148 l'esempio di implementazione di \code{sleep}. Abbiamo accennato in
2149 sez.~\ref{sec:sig_sigaction} come con \func{sigaction} sia possibile bloccare
2150 \const{SIGALRM} nell'installazione dei gestori degli altri segnali, per poter
2151 usare l'implementazione vista in fig.~\ref{fig:sig_sleep_incomplete} senza
2152 interferenze. Questo però comporta una precauzione ulteriore al semplice uso
2153 della funzione, vediamo allora come usando la nuova interfaccia è possibile
2154 ottenere un'implementazione, riportata in fig.~\ref{fig:sig_sleep_ok} che non
2155 presenta neanche questa necessità.
2157 \begin{figure}[!htb]
2158 \footnotesize \centering
2159 \begin{minipage}[c]{15.6cm}
2160 \includecodesample{listati/sleep.c}
2163 \caption{Una implementazione completa di \func{sleep}.}
2164 \label{fig:sig_sleep_ok}
2167 Per evitare i problemi di interferenza con gli altri segnali in questo caso
2168 non si è usato l'approccio di fig.~\ref{fig:sig_sleep_incomplete} evitando
2169 l'uso di \func{longjmp}. Come in precedenza il gestore (\texttt{\small 27-30})
2170 non esegue nessuna operazione, limitandosi a ritornare per interrompere il
2171 programma messo in attesa.
2173 La prima parte della funzione (\texttt{\small 6-10}) provvede ad installare
2174 l'opportuno gestore per \const{SIGALRM}, salvando quello originario, che
2175 sarà ripristinato alla conclusione della stessa (\texttt{\small 23}); il passo
2176 successivo è quello di bloccare \const{SIGALRM} (\texttt{\small 11-14}) per
2177 evitare che esso possa essere ricevuto dal processo fra l'esecuzione di
2178 \func{alarm} (\texttt{\small 16}) e la sospensione dello stesso. Nel fare
2179 questo si salva la maschera corrente dei segnali, che sarà ripristinata alla
2180 fine (\texttt{\small 22}), e al contempo si prepara la maschera dei segnali
2181 \var{sleep\_mask} per riattivare \const{SIGALRM} all'esecuzione di
2184 In questo modo non sono più possibili \itindex{race~condition} \textit{race
2185 condition} dato che \const{SIGALRM} viene disabilitato con
2186 \func{sigprocmask} fino alla chiamata di \func{sigsuspend}. Questo metodo è
2187 assolutamente generale e può essere applicato a qualunque altra situazione in
2188 cui si deve attendere per un segnale, i passi sono sempre i seguenti:
2190 \item leggere la maschera dei segnali corrente e bloccare il segnale voluto
2191 con \func{sigprocmask};
2192 \item mandare il processo in attesa con \func{sigsuspend} abilitando la
2193 ricezione del segnale voluto;
2194 \item ripristinare la maschera dei segnali originaria.
2196 Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi
2197 riabilitarla immediatamente dopo, in questo modo si evita il
2198 \itindex{deadlock} deadlock dovuto all'arrivo del segnale prima
2199 dell'esecuzione di \func{sigsuspend}.
2201 \itindend{signal~mask}
2204 \subsection{Ulteriori funzioni di gestione}
2205 \label{sec:sig_specific_features}
2207 In questo ultimo paragrafo esamineremo le rimanenti funzioni di gestione dei
2208 segnali non descritte finora, relative agli aspetti meno utilizzati e più
2209 ``\textsl{esoterici}'' della interfaccia.
2211 La prima di queste funzioni è \funcd{sigpending}, anch'essa introdotta dallo
2212 standard POSIX.1; il suo prototipo è:
2213 \begin{prototype}{signal.h}
2214 {int sigpending(sigset\_t *set)}
2216 Scrive in \param{set} l'insieme dei segnali pendenti.
2218 \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
2222 La funzione permette di ricavare quali sono i segnali pendenti per il processo
2223 in corso, cioè i segnali che sono stati inviati dal kernel ma non sono stati
2224 ancora ricevuti dal processo in quanto bloccati. Non esiste una funzione
2225 equivalente nella vecchia interfaccia, ma essa è tutto sommato poco utile,
2226 dato che essa può solo assicurare che un segnale è stato inviato, dato che
2227 escluderne l'avvenuto invio al momento della chiamata non significa nulla
2228 rispetto a quanto potrebbe essere in un qualunque momento successivo.
2230 Una delle caratteristiche di BSD, disponibile anche in Linux, è la possibilità
2231 di usare uno \itindex{stack} \textit{stack} alternativo per i segnali; è cioè
2232 possibile fare usare al sistema un altro \itindex{stack} \textit{stack}
2233 (invece di quello relativo al processo, vedi sez.~\ref{sec:proc_mem_layout})
2234 solo durante l'esecuzione di un gestore. L'uso di uno \textit{stack}
2235 alternativo è del tutto trasparente ai gestori, occorre però seguire una certa
2238 \item allocare un'area di memoria di dimensione sufficiente da usare come
2239 \textit{stack} alternativo;
2240 \item usare la funzione \func{sigaltstack} per rendere noto al sistema
2241 l'esistenza e la locazione dello \textit{stack} alternativo;
2242 \item quando si installa un gestore occorre usare \func{sigaction}
2243 specificando il flag \const{SA\_ONSTACK} (vedi tab.~\ref{tab:sig_sa_flag})
2244 per dire al sistema di usare lo \textit{stack} alternativo durante
2245 l'esecuzione del gestore.
2248 In genere il primo passo viene effettuato allocando un'opportuna area di
2249 memoria con \code{malloc}; in \file{signal.h} sono definite due costanti,
2250 \const{SIGSTKSZ} e \const{MINSIGSTKSZ}, che possono essere utilizzate per
2251 allocare una quantità di spazio opportuna, in modo da evitare overflow. La
2252 prima delle due è la dimensione canonica per uno \itindex{stack}
2253 \textit{stack} di segnali e di norma è sufficiente per tutti gli usi normali.
2255 La seconda è lo spazio che occorre al sistema per essere in grado di lanciare
2256 il gestore e la dimensione di uno \textit{stack} alternativo deve essere
2257 sempre maggiore di questo valore. Quando si conosce esattamente quanto è lo
2258 spazio necessario al gestore gli si può aggiungere questo valore per allocare
2259 uno \itindex{stack} \textit{stack} di dimensione sufficiente.
2261 Come accennato, per poter essere usato, lo \itindex{stack} \textit{stack} per
2262 i segnali deve essere indicato al sistema attraverso la funzione
2263 \funcd{sigaltstack}; il suo prototipo è:
2264 \begin{prototype}{signal.h}
2265 {int sigaltstack(const stack\_t *ss, stack\_t *oss)}
2267 Installa un nuovo \textit{stack} per i segnali.
2269 \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
2270 errore, nel qual caso \var{errno} assumerà i valori:
2273 \item[\errcode{ENOMEM}] la dimensione specificata per il nuovo
2274 \textit{stack} è minore di \const{MINSIGSTKSZ}.
2275 \item[\errcode{EPERM}] uno degli indirizzi non è valido.
2276 \item[\errcode{EFAULT}] si è cercato di cambiare lo \textit{stack}
2277 alternativo mentre questo è attivo (cioè il processo è in esecuzione su di
2279 \item[\errcode{EINVAL}] \param{ss} non è nullo e \var{ss\_flags} contiene un
2280 valore diverso da zero che non è \const{SS\_DISABLE}.
2284 La funzione prende come argomenti puntatori ad una struttura di tipo
2285 \var{stack\_t}, definita in fig.~\ref{fig:sig_stack_t}. I due valori
2286 \param{ss} e \param{oss}, se non nulli, indicano rispettivamente il nuovo
2287 \itindex{stack} \textit{stack} da installare e quello corrente (che viene
2288 restituito dalla funzione per un successivo ripristino).
2290 \begin{figure}[!htb]
2291 \footnotesize \centering
2292 \begin{minipage}[c]{15cm}
2293 \includestruct{listati/stack_t.h}
2296 \caption{La struttura \structd{stack\_t}.}
2297 \label{fig:sig_stack_t}
2300 Il campo \var{ss\_sp} di \struct{stack\_t} indica l'indirizzo base dello
2301 \itindex{stack} \textit{stack}, mentre \var{ss\_size} ne indica la dimensione;
2302 il campo \var{ss\_flags} invece indica lo stato dello \textit{stack}.
2303 Nell'indicare un nuovo \textit{stack} occorre inizializzare \var{ss\_sp} e
2304 \var{ss\_size} rispettivamente al puntatore e alla dimensione della memoria
2305 allocata, mentre \var{ss\_flags} deve essere nullo. Se invece si vuole
2306 disabilitare uno \textit{stack} occorre indicare \const{SS\_DISABLE} come
2307 valore di \var{ss\_flags} e gli altri valori saranno ignorati.
2309 Se \param{oss} non è nullo verrà restituito dalla funzione indirizzo e
2310 dimensione dello \itindex{stack} \textit{stack} corrente nei relativi campi,
2311 mentre \var{ss\_flags} potrà assumere il valore \const{SS\_ONSTACK} se il
2312 processo è in esecuzione sullo \textit{stack} alternativo (nel qual caso non è
2313 possibile cambiarlo) e \const{SS\_DISABLE} se questo non è abilitato.
2315 In genere si installa uno \itindex{stack} \textit{stack} alternativo per i
2316 segnali quando si teme di avere problemi di esaurimento dello \textit{stack}
2317 standard o di superamento di un limite (vedi
2318 sez.~\ref{sec:sys_resource_limit}) imposto con chiamate del tipo
2319 \code{setrlimit(RLIMIT\_STACK, \&rlim)}. In tal caso infatti si avrebbe un
2320 segnale di \const{SIGSEGV}, che potrebbe essere gestito soltanto avendo
2321 abilitato uno \itindex{stack} \textit{stack} alternativo.
2323 Si tenga presente che le funzioni chiamate durante l'esecuzione sullo
2324 \textit{stack} alternativo continueranno ad usare quest'ultimo, che, al
2325 contrario di quanto avviene per lo \itindex{stack} \textit{stack} ordinario
2326 dei processi, non si accresce automaticamente (ed infatti eccederne le
2327 dimensioni può portare a conseguenze imprevedibili). Si ricordi infine che
2328 una chiamata ad una funzione della famiglia \func{exec} cancella ogni
2329 \textit{stack} alternativo.
2331 Abbiamo visto in fig.~\ref{fig:sig_sleep_incomplete} come si possa usare
2332 \func{longjmp} per uscire da un gestore rientrando direttamente nel corpo
2333 del programma; sappiamo però che nell'esecuzione di un gestore il segnale
2334 che l'ha invocato viene bloccato, e abbiamo detto che possiamo ulteriormente
2335 modificarlo con \func{sigprocmask}.
2337 Resta quindi il problema di cosa succede alla maschera dei segnali quando si
2338 esce da un gestore usando questa funzione. Il comportamento dipende
2339 dall'implementazione; in particolare la semantica usata da BSD prevede che sia
2340 ripristinata la maschera dei segnali precedente l'invocazione, come per un
2341 normale ritorno, mentre quella usata da System V no.
2343 Lo standard POSIX.1 non specifica questo comportamento per \func{setjmp} e
2344 \func{longjmp}, ed il comportamento delle \acr{glibc} dipende da quale delle
2345 caratteristiche si sono abilitate con le macro viste in
2346 sez.~\ref{sec:intro_gcc_glibc_std}.
2348 Lo standard POSIX però prevede anche la presenza di altre due funzioni
2349 \funcd{sigsetjmp} e \funcd{siglongjmp}, che permettono di decidere quale dei
2350 due comportamenti il programma deve assumere; i loro prototipi sono:
2354 \funcdecl{int sigsetjmp(sigjmp\_buf env, int savesigs)} Salva il contesto
2355 dello \textit{stack} per un \index{salto~non-locale} salto non-locale.
2357 \funcdecl{void siglongjmp(sigjmp\_buf env, int val)} Esegue un salto
2358 non-locale su un precedente contesto.
2360 \bodydesc{Le due funzioni sono identiche alle analoghe \func{setjmp} e
2361 \func{longjmp} di sez.~\ref{sec:proc_longjmp}, ma consentono di specificare
2362 il comportamento sul ripristino o meno della maschera dei segnali.}
2365 Le due funzioni prendono come primo argomento la variabile su cui viene
2366 salvato il contesto dello \itindex{stack} \textit{stack} per permettere il
2367 \index{salto~non-locale} salto non-locale; nel caso specifico essa è di tipo
2368 \type{sigjmp\_buf}, e non \type{jmp\_buf} come per le analoghe di
2369 sez.~\ref{sec:proc_longjmp} in quanto in questo caso viene salvata anche la
2370 maschera dei segnali.
2372 Nel caso di \func{sigsetjmp}, se si specifica un valore di \param{savesigs}
2373 diverso da zero la maschera dei valori sarà salvata in \param{env} e
2374 ripristinata in un successivo \func{siglongjmp}; quest'ultima funzione, a
2375 parte l'uso di \type{sigjmp\_buf} per \param{env}, è assolutamente identica a
2379 \subsection{Criteri di programmazione per i gestori dei segnali}
2380 \label{sec:sig_signal_handler}
2382 Abbiamo finora parlato dei gestori dei segnali come funzioni chiamate in
2383 corrispondenza della consegna di un segnale. In realtà un gestore non può
2384 essere una funzione qualunque, in quanto esso può essere eseguito in
2385 corrispondenza all'interruzione in un punto qualunque del programma principale,
2386 ed ad esempio può essere problematico chiamare all'interno di un gestore di
2387 segnali la stessa funzione che dal segnale è stata interrotta.
2389 \index{funzioni!sicure|(}
2391 Il concetto è comunque più generale e porta ad una distinzione fra quelle che
2392 che POSIX chiama \textsl{funzioni insicure} (\textit{unsafe function}) e
2393 \textsl{funzioni sicure} (\textit{safe function}); quando un segnale
2394 interrompe una funzione insicura ed il gestore chiama al suo interno una
2395 funzione insicura il sistema può dare luogo ad un comportamento indefinito.
2397 Tutto questo significa che un gestore di segnale deve essere programmato con
2398 molta cura per evitare questa evenienza, pertanto è non è possibile chiamare
2399 al suo interno una funzione qualunque, e si può ricorrere soltanto all'uso di
2402 L'elenco delle funzioni sicure varia a secondo dello standard a cui si fa
2403 riferimento, secondo quanto riportato dallo standard POSIX 1003.1 nella
2404 revisione del 2003, le ``\textit{signal safe function}'' che possono essere
2405 chiamate anche all'interno di un gestore di segnali sono quelle della lista
2406 riportata in fig.~\ref{fig:sig_safe_functions}.
2408 \begin{figure}[!htb]
2409 \footnotesize \centering
2410 \begin{minipage}[c]{15cm}
2411 \func{\_exit}, \func{abort}, \func{accept}, \func{access},
2412 \func{aio\_error} \func{aio\_return}, \func{aio\_suspend}, \func{alarm},
2413 \func{bind}, \func{cfgetispeed}, \func{cfgetospeed}, \func{cfsetispeed},
2414 \func{cfsetospeed}, \func{chdir}, \func{chmod}, \func{chown},
2415 \func{clock\_gettime}, \func{close}, \func{connect}, \func{creat},
2416 \func{dup}, \func{dup2}, \func{execle}, \func{execve}, \func{fchmod},
2417 \func{fchown}, \func{fcntl}, \func{fdatasync}, \func{fork},
2418 \func{fpathconf}, \func{fstat}, \func{fsync}, \func{ftruncate},
2419 \func{getegid}, \func{geteuid}, \func{getgid}, \func{getgroups},
2420 \func{getpeername}, \func{getpgrp}, \func{getpid}, \func{getppid},
2421 \func{getsockname}, \func{getsockopt}, \func{getuid}, \func{kill},
2422 \func{link}, \func{listen}, \func{lseek}, \func{lstat}, \func{mkdir},
2423 \func{mkfifo}, \func{open}, \func{pathconf}, \func{pause}, \func{pipe},
2424 \func{poll}, \func{posix\_trace\_event}, \func{pselect}, \func{raise},
2425 \func{read}, \func{readlink}, \func{recv}, \func{recvfrom},
2426 \func{recvmsg}, \func{rename}, \func{rmdir}, \func{select},
2427 \func{sem\_post}, \func{send}, \func{sendmsg}, \func{sendto},
2428 \func{setgid}, \func{setpgid}, \func{setsid}, \func{setsockopt},
2429 \func{setuid}, \func{shutdown}, \func{sigaction}, \func{sigaddset},
2430 \func{sigdelset}, \func{sigemptyset}, \func{sigfillset},
2431 \func{sigismember}, \func{signal}, \func{sigpause}, \func{sigpending},
2432 \func{sigprocmask}, \func{sigqueue}, \func{sigset}, \func{sigsuspend},
2433 \func{sleep}, \func{socket}, \func{socketpair}, \func{stat},
2434 \func{symlink}, \func{sysconf}, \func{tcdrain}, \func{tcflow},
2435 \func{tcflush}, \func{tcgetattr}, \func{tcgetgrp}, \func{tcsendbreak},
2436 \func{tcsetattr}, \func{tcsetpgrp}, \func{time}, \func{timer\_getoverrun},
2437 \func{timer\_gettime}, \func{timer\_settime}, \func{times}, \func{umask},
2438 \func{uname}, \func{unlink}, \func{utime}, \func{wait}, \func{waitpid},
2442 \caption{Elenco delle funzioni sicure secondo lo standard POSIX
2444 \label{fig:sig_safe_functions}
2447 \index{funzioni!sicure|)}
2449 Per questo motivo è opportuno mantenere al minimo indispensabile le operazioni
2450 effettuate all'interno di un gestore di segnali, qualora si debbano compiere
2451 operazioni complesse è sempre preferibile utilizzare la tecnica in cui si usa
2452 il gestore per impostare il valore di una qualche variabile globale, e poi si
2453 eseguono le operazioni complesse nel programma verificando (con tutti gli
2454 accorgimenti visti in precedenza) il valore di questa variabile tutte le volte
2455 che si è rilevata una interruzione dovuta ad un segnale.
2458 \section{Funzionalità avanzate}
2459 \label{sec:sig_advanced_signal}
2462 Tratteremo in questa ultima sezione alcune funzionalità avanzate relativa ai
2463 segnali ed in generale ai meccanismi di notifica, a partire dalla funzioni
2464 introdotte per la gestione dei cosiddetti ``\textsl{segnali real-time}'', alla
2465 gestione avanzata delle temporizzazioni e le nuove interfacce per la gestione
2466 di segnali ed eventi attraverso l'uso di file descriptor.
2468 \subsection{I segnali real-time}
2469 \label{sec:sig_real_time}
2471 Lo standard POSIX.1b, nel definire una serie di nuove interfacce per i servizi
2472 \textit{real-time}, ha introdotto una estensione del modello classico dei
2473 segnali che presenta dei significativi miglioramenti,\footnote{questa
2474 estensione è stata introdotta in Linux a partire dal kernel 2.1.43, e dalle
2475 \acr{glibc} 2.1.} in particolare sono stati superati tre limiti fondamentali
2476 dei segnali classici:
2477 \begin{basedescript}{\desclabelwidth{1cm}\desclabelstyle{\nextlinelabel}}
2478 \item[I segnali non sono accumulati]
2479 se più segnali vengono generati prima dell'esecuzione di un gestore
2480 questo sarà eseguito una sola volta, ed il processo non sarà in grado di
2481 accorgersi di quante volte l'evento che ha generato il segnale è accaduto;
2482 \item[I segnali non trasportano informazione]
2483 i segnali classici non prevedono altra informazione sull'evento
2484 che li ha generati se non il fatto che sono stati emessi (tutta
2485 l'informazione che il kernel associa ad un segnale è il suo numero);
2486 \item[I segnali non hanno un ordine di consegna]
2487 l'ordine in cui diversi segnali vengono consegnati è casuale e non
2488 prevedibile. Non è possibile stabilire una priorità per cui la reazione a
2489 certi segnali ha la precedenza rispetto ad altri.
2492 Per poter superare queste limitazioni lo standard POSIX.1b ha introdotto delle
2493 nuove caratteristiche, che sono state associate ad una nuova classe di
2494 segnali, che vengono chiamati \textsl{segnali real-time}, in particolare le
2495 funzionalità aggiunte sono:
2498 \item i segnali sono inseriti in una coda che permette di consegnare istanze
2499 multiple dello stesso segnale qualora esso venga inviato più volte prima
2500 dell'esecuzione del gestore; si assicura così che il processo riceva un
2501 segnale per ogni occorrenza dell'evento che lo genera.
2502 \item è stata introdotta una priorità nella consegna dei segnali: i segnali
2503 vengono consegnati in ordine a seconda del loro valore, partendo da quelli
2504 con un numero minore, che pertanto hanno una priorità maggiore.
2505 \item è stata introdotta la possibilità di restituire dei dati al gestore,
2506 attraverso l'uso di un apposito campo \var{si\_value} nella struttura
2507 \struct{siginfo\_t}, accessibile tramite gestori di tipo
2508 \var{sa\_sigaction}.
2511 Tutte queste nuove funzionalità eccetto l'ultima, che, come illustrato in
2512 sez.~\ref{sec:sig_sigaction}, è disponibile anche con i segnali ordinari, si
2513 applicano solo ai nuovi segnali \textit{real-time}; questi ultimi sono
2514 accessibili in un intervallo di valori specificati dalle due costanti
2515 \const{SIGRTMIN} e \const{SIGRTMAX},\footnote{in Linux di solito (cioè sulla
2516 piattaforma i386) il primo valore è 33, ed il secondo \code{\_NSIG-1}, che
2517 di norma è 64, per un totale di 32 segnali disponibili, contro gli almeno 8
2518 richiesti da POSIX.1b.} che specificano il numero minimo e massimo associato
2519 ad un segnale real-time.
2521 % TODO rivedere secondo man 7 signal con le informazioni aggiornate sul numero
2522 % di segnali real-time disponibili
2524 I segnali con un numero più basso hanno una priorità maggiore e vengono
2525 consegnati per primi, inoltre i segnali \textit{real-time} non possono
2526 interrompere l'esecuzione di un gestore di un segnale a priorità più alta; la
2527 loro azione predefinita è quella di terminare il programma. I segnali
2528 ordinari hanno tutti la stessa priorità, che è più alta di quella di qualunque
2529 segnale \textit{real-time}.\footnote{lo standard non definisce niente al
2530 riguardo ma Linux, come molte altre implementazioni, adotta questa
2534 Si tenga presente che questi nuovi segnali non sono associati a nessun evento
2535 specifico, a meno di non utilizzarli in meccanismi di notifica come quelli per
2536 l'I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io}) o per le code di
2537 messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}); pertanto devono essere
2538 inviati esplicitamente.
2540 Inoltre, per poter usufruire della capacità di restituire dei dati, i relativi
2541 gestori devono essere installati con \func{sigaction}, specificando per
2542 \var{sa\_flags} la modalità \const{SA\_SIGINFO} che permette di utilizzare la
2543 forma estesa \var{sa\_sigaction} (vedi sez.~\ref{sec:sig_sigaction}). In
2544 questo modo tutti i segnali real-time possono restituire al gestore una serie
2545 di informazioni aggiuntive attraverso l'argomento \struct{siginfo\_t}, la cui
2546 definizione è stata già vista in fig.~\ref{fig:sig_siginfo_t}, nella
2547 trattazione dei gestori in forma estesa.
2549 In particolare i campi utilizzati dai segnali real-time sono \var{si\_pid} e
2550 \var{si\_uid} in cui vengono memorizzati rispettivamente il \acr{pid} e
2551 l'user-ID effettivo del processo che ha inviato il segnale, mentre per la
2552 restituzione dei dati viene usato il campo \var{si\_value}.
2554 Questo è una \ctyp{union} di tipo \struct{sigval\_t} (la sua definizione è in
2555 fig.~\ref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico,
2556 se usata nella forma \var{sival\_int}, o un indirizzo, se usata nella forma
2557 \var{sival\_ptr}. L'unione viene usata dai segnali real-time e da vari
2558 meccanismi di notifica\footnote{un campo di tipo \struct{sigval\_t} è presente
2559 anche nella struttura \struct{sigevent} (definita in
2560 fig.~\ref{fig:file_sigevent}) che viene usata dai meccanismi di notifica
2561 come quelli per l'I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io}) o
2562 le code di messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}).} per
2563 restituire dati al gestore del segnale; in alcune definizioni essa viene
2564 identificata anche come \code{union sigval}.
2566 \begin{figure}[!htb]
2567 \footnotesize \centering
2568 \begin{minipage}[c]{15cm}
2569 \includestruct{listati/sigval_t.h}
2572 \caption{La unione \structd{sigval\_t}.}
2573 \label{fig:sig_sigval}
2576 A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
2577 inviare segnali \textit{real-time}, poiché non è in grado di fornire alcun
2578 valore per \struct{sigval\_t}; per questo motivo lo standard ha previsto una
2579 nuova funzione, \funcd{sigqueue}, il cui prototipo è:
2580 \begin{prototype}{signal.h}
2581 {int sigqueue(pid\_t pid, int signo, const sigval\_t value)}
2583 Invia il segnale \param{signo} al processo \param{pid}, restituendo al
2584 gestore il valore \param{value}.
2586 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
2587 errore, nel qual caso \var{errno} assumerà uno dei valori:
2589 \item[\errcode{EAGAIN}] la coda è esaurita, ci sono già
2590 \const{SIGQUEUE\_MAX} segnali in attesa si consegna.
2591 \item[\errcode{EPERM}] non si hanno privilegi appropriati per inviare il
2592 segnale al processo specificato.
2593 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2594 \item[\errcode{EINVAL}] si è specificato un valore non valido per
2597 ed inoltre \errval{ENOMEM}.}
2600 Il comportamento della funzione è analogo a quello di \func{kill}, ed i
2601 privilegi occorrenti ad inviare il segnale ad un determinato processo sono gli
2602 stessi; un valore nullo di \param{signo} permette di verificare le condizioni
2603 di errore senza inviare nessun segnale.
2605 Se il segnale è bloccato la funzione ritorna immediatamente, se si è
2606 installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili,
2607 (vale a dire che c'è posto\footnote{la profondità della coda è indicata dalla
2608 costante \const{SIGQUEUE\_MAX}, una della tante costanti di sistema definite
2609 dallo standard POSIX che non abbiamo riportato esplicitamente in
2610 sez.~\ref{sec:sys_limits}; il suo valore minimo secondo lo standard,
2611 \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux questo è uno
2612 dei parametri del kernel impostabili sia con \func{sysctl}, che scrivendolo
2613 direttamente in \procfile{/proc/sys/kernel/rtsig-max}, il valore predefinito
2614 è di 1024.} nella coda dei segnali real-time) esso viene inserito e diventa
2615 pendente; una volta consegnato riporterà nel campo \var{si\_code} di
2616 \struct{siginfo\_t} il valore \const{SI\_QUEUE} e il campo \var{si\_value}
2617 riceverà quanto inviato con \param{value}. Se invece si è installato un
2618 gestore nella forma classica il segnale sarà generato, ma tutte le
2619 caratteristiche tipiche dei segnali real-time (priorità e coda) saranno perse.
2621 Lo standard POSIX.1b definisce inoltre delle nuove funzioni che permettono di
2622 gestire l'attesa di segnali specifici su una coda, esse servono in particolar
2623 modo nel caso dei \itindex{thread} \textit{thread}, in cui si possono usare i
2624 segnali real-time come meccanismi di comunicazione elementare; la prima di
2625 queste funzioni è \funcd{sigwait}, il cui prototipo è:
2626 \begin{prototype}{signal.h}
2627 {int sigwait(const sigset\_t *set, int *sig)}
2629 Attende che uno dei segnali specificati in \param{set} sia pendente.
2631 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
2632 errore, nel qual caso \var{errno} assumerà uno dei valori:
2634 \item[\errcode{EINTR}] la funzione è stata interrotta.
2635 \item[\errcode{EINVAL}] si è specificato un valore non valido per
2638 ed inoltre \errval{EFAULT}.}
2641 La funzione estrae dall'insieme dei segnali pendenti uno qualunque dei segnali
2642 specificati da \param{set}, il cui valore viene restituito in \param{sig}. Se
2643 sono pendenti più segnali, viene estratto quello a priorità più alta (cioè con
2644 il numero più basso). Se, nel caso di segnali real-time, c'è più di un segnale
2645 pendente, ne verrà estratto solo uno. Una volta estratto il segnale non verrà
2646 più consegnato, e se era in una coda il suo posto sarà liberato. Se non c'è
2647 nessun segnale pendente il processo viene bloccato fintanto che non ne arriva
2650 Per un funzionamento corretto la funzione richiede che alla sua chiamata i
2651 segnali di \param{set} siano bloccati. In caso contrario si avrebbe un
2652 conflitto con gli eventuali gestori: pertanto non si deve utilizzare per
2653 lo stesso segnale questa funzione e \func{sigaction}. Se questo non avviene il
2654 comportamento del sistema è indeterminato: il segnale può sia essere
2655 consegnato che essere ricevuto da \func{sigwait}, il tutto in maniera non
2658 Lo standard POSIX.1b definisce altre due funzioni, anch'esse usate
2659 prevalentemente con i \itindex{thread} \textit{thread}; \funcd{sigwaitinfo} e
2660 \funcd{sigtimedwait}, i relativi prototipi sono:
2664 \funcdecl{int sigwaitinfo(const sigset\_t *set, siginfo\_t *info)}
2666 Analoga a \func{sigwait}, ma riceve anche le informazioni associate al
2667 segnale in \param{info}.
2669 \funcdecl{int sigtimedwait(const sigset\_t *set, siginfo\_t *value, const
2670 struct timespec *info)}
2672 Analoga a \func{sigwaitinfo}, con un la possibilità di specificare un
2673 timeout in \param{timeout}.
2676 \bodydesc{Le funzioni restituiscono 0 in caso di successo e $-1$ in caso di
2677 errore, nel qual caso \var{errno} assumerà uno dei valori già visti per
2678 \func{sigwait}, ai quali si aggiunge, per \func{sigtimedwait}:
2680 \item[\errcode{EAGAIN}] si è superato il timeout senza che un segnale atteso
2686 Entrambe le funzioni sono estensioni di \func{sigwait}. La prima permette di
2687 ricevere, oltre al numero del segnale, anche le informazioni ad esso associate
2688 tramite \param{info}; in particolare viene restituito il numero del segnale
2689 nel campo \var{si\_signo}, la sua causa in \var{si\_code}, e se il segnale è
2690 stato immesso sulla coda con \func{sigqueue}, il valore di ritorno ad esso
2691 associato viene riportato in \var{si\_value}, che altrimenti è indefinito.
2693 La seconda è identica alla prima ma in più permette di specificare un timeout,
2694 scaduto il quale ritornerà con un errore. Se si specifica un puntatore nullo
2695 il comportamento sarà identico a \func{sigwaitinfo}, se si specifica un tempo
2696 di timeout nullo, e non ci sono segnali pendenti la funzione ritornerà
2697 immediatamente; in questo modo si può eliminare un segnale dalla coda senza
2698 dover essere bloccati qualora esso non sia presente.
2702 L'uso di queste funzioni è principalmente associato alla gestione dei segnali
2703 con i \textit{thread}. In genere esse vengono chiamate dal \textit{thread}
2704 incaricato della gestione, che al ritorno della funzione esegue il codice che
2705 usualmente sarebbe messo nel gestore, per poi ripetere la chiamata per
2706 mettersi in attesa del segnale successivo. Questo ovviamente comporta che non
2707 devono essere installati gestori, che solo il \textit{thread} di gestione deve
2708 usare \func{sigwait} e che, per evitare che venga eseguita l'azione
2709 predefinita, i segnali gestiti in questa maniera devono essere mascherati per
2710 tutti i \textit{thread}, compreso quello dedicato alla gestione, che potrebbe
2711 riceverlo fra due chiamate successive.
2716 \subsection{La gestione avanzata delle temporizzazioni}
2717 \label{sec:sig_timer_adv}
2719 % TODO trattare i Posix timer, e le fuzioni:
2720 % clock_getres clock_gettime clock_settime (vedi man page)
2721 % timer_getoverrun, timer_gettime, timer_settime, timer_create, timer_delete
2724 \subsection{Le interfacce per la notifica attraverso i file descriptor}
2725 \label{sec:sig_signalfd_eventfd}
2728 % TODO trattare qui eventfd signalfd e timerfd introdotte con il 2.6.22
2729 % timerfd è stata tolta nel 2.6.23 e rifatta per bene nel 2.6.25
2730 % vedi: http://lwn.net/Articles/233462/
2731 % http://lwn.net/Articles/245533/
2732 % http://lwn.net/Articles/267331/
2737 % LocalWords: kernel POSIX timer shell control ctrl kill raise signal handler
2738 % LocalWords: reliable unreliable fig race condition sez struct process table
2739 % LocalWords: delivered pending scheduler sigpending l'I suspend SIGKILL wait
2740 % LocalWords: SIGSTOP sigaction waitpid dump stack debugger nell'header NSIG
2741 % LocalWords: tab BSD SUSv SIGHUP PL Hangup SIGINT Interrupt SIGQUIT Quit AEF
2742 % LocalWords: SIGILL SIGABRT abort SIGFPE SIGSEGV SIGPIPE SIGALRM alarm SIGUSR
2743 % LocalWords: SIGTERM SIGCHLD SIGCONT SIGTSTP SIGTTIN SIGTTOU SIGBUS bad SL of
2744 % LocalWords: memory access SIGPOLL Pollable event Sys SIGIO SIGPROF profiling
2745 % LocalWords: SIGSYS SVID SIGTRAP breakpoint SIGURG urgent socket Virtual IOT
2746 % LocalWords: clock SIGXCPU SIGXFSZ SIGIOT trap SIGEMT SIGSTKFLT SIGCLD SIGPWR
2747 % LocalWords: SIGINFO SIGLOST lock NFS SIGWINCH Sun SIGUNUSED fault point heap
2748 % LocalWords: exception l'overflow illegal instruction overflow segment error
2749 % LocalWords: violation system call interrupt INTR hang SIGVTALRM virtual SUSP
2750 % LocalWords: profilazione fcntl descriptor sleep interactive Broken FIFO lost
2751 % LocalWords: EPIPE Resource advisory client limit exceeded size window change
2752 % LocalWords: strsignal psignal SOURCE strerror string char int signum perror
2753 % LocalWords: void sig const sys siglist L'array decr fork exec DFL IGN ioctl
2754 % LocalWords: EINTR glibc TEMP FAILURE RETRY expr multitasking SVr sighandler
2755 % LocalWords: ERR libc bsd sysv XOPEN EINVAL pid errno ESRCH EPERM getpid init
2756 % LocalWords: killpg pidgrp group unistd unsigned seconds all' setitimer which
2757 % LocalWords: itimerval value ovalue EFAULT ITIMER it interval timeval ms VIRT
2758 % LocalWords: getitimer stdlib stream atexit exit usleep long usec nanosleep
2759 % LocalWords: timespec req rem HZ scheduling SCHED RR SigHand forktest WNOHANG
2760 % LocalWords: deadlock longjmp setjmp sigset sigemptyset sigfillset sigaddset
2761 % LocalWords: sigdelset sigismember act oldact restorer mask NOCLDSTOP ONESHOT
2762 % LocalWords: RESETHAND RESTART NOMASK NODEFER ONSTACK sigcontext union signo
2763 % LocalWords: siginfo bits uid addr fd inline like blocked atomic sigprocmask
2764 % LocalWords: how oldset BLOCK UNBLOCK SETMASK sigsuspend sigaltstack malloc
2765 % LocalWords: SIGSTKSZ MINSIGSTKSZ ss oss ENOMEM flags DISABLE sp setrlimit LB
2766 % LocalWords: RLIMIT rlim sigsetjmp siglongjmp sigjmp buf env savesigs jmp ptr
2767 % LocalWords: SIGRTMIN SIGRTMAX sigval sigevent sigqueue EAGAIN sysctl safe
2768 % LocalWords: QUEUE thread sigwait sigwaitinfo sigtimedwait info DEF SLB bind
2769 % LocalWords: function accept return cfgetispeed cfgetospeed cfsetispeed chdir
2770 % LocalWords: cfsetospeed chmod chown gettime close connect creat dup execle
2771 % LocalWords: execve fchmod fchown fdatasync fpathconf fstat fsync ftruncate
2772 % LocalWords: getegid geteuid getgid getgroups getpeername getpgrp getppid sem
2773 % LocalWords: getsockname getsockopt getuid listen lseek lstat mkdir mkfifo
2774 % LocalWords: pathconf poll posix pselect read readlink recv recvfrom recvmsg
2775 % LocalWords: rename rmdir select send sendmsg sendto setgid setpgid setsid
2776 % LocalWords: setsockopt setuid shutdown sigpause socketpair stat symlink page
2777 % LocalWords: sysconf tcdrain tcflow tcflush tcgetattr tcgetgrp tcsendbreak
2778 % LocalWords: tcsetattr tcsetpgrp getoverrun times umask uname unlink utime
2779 % LocalWords: write sival SIVGTALRM NOCLDWAIT MESGQ ASYNCIO TKILL tkill tgkill
2780 % LocalWords: ILL ILLOPC ILLOPN ILLADR ILLTRP PRVOPC PRVREG COPROC BADSTK FPE
2781 % LocalWords: INTDIV INTOVF FLTDIV FLTOVF FLTUND underflow FLTRES FLTINV SEGV
2782 % LocalWords: FLTSUB MAPERR ACCERR ADRALN ADRERR OBJERR BRKPT CLD EXITED MSG
2783 % LocalWords: KILLED DUMPED TRAPPED STOPPED CONTINUED PRI HUP SigFunc jiffies
2787 %%% Local Variables:
2789 %%% TeX-master: "gapil"