3 %% Copyright (C) 2000-2012 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 che
73 può essere stata specificata dall'utente, nel qual caso si dice che si
74 \textsl{intercetta} il segnale. Riprendendo la terminologia originale da qui
75 in avanti faremo riferimento a questa funzione come al \textsl{gestore} del
76 segnale, traduzione approssimata dell'inglese \textit{signal handler}.
79 \subsection{Le \textsl{semantiche} del funzionamento dei segnali}
80 \label{sec:sig_semantics}
82 Negli anni il comportamento del sistema in risposta ai segnali è stato
83 modificato in vari modi nelle differenti implementazioni di Unix. Si possono
84 individuare due tipologie fondamentali di comportamento dei segnali (dette
85 \textsl{semantiche}) che vengono chiamate rispettivamente \textsl{semantica
86 affidabile} (o \textit{reliable}) e \textsl{semantica inaffidabile} (o
89 Nella \textsl{semantica inaffidabile}, che veniva implementata dalle prime
90 versioni di Unix, la funzione di gestione del segnale specificata dall'utente
91 non restava attiva una volta che era stata eseguita; era perciò compito
92 dell'utente ripetere l'installazione dello stesso all'interno del
93 \textsl{gestore} del segnale in tutti quei casi in cui si voleva che esso
97 \footnotesize \centering
98 \begin{minipage}[c]{\codesamplewidth}
99 \includecodesample{listati/unreliable_sig.c}
102 \caption{Esempio di codice di un gestore di segnale per la semantica
104 \label{fig:sig_old_handler}
107 In questo caso però è possibile una situazione in cui i segnali possono essere
108 perduti. Si consideri il segmento di codice riportato in
109 fig.~\ref{fig:sig_old_handler}: nel programma principale viene installato un
110 gestore (\texttt{\small 5}), la cui prima operazione (\texttt{\small 11}) è
111 quella di reinstallare se stesso. Se nell'esecuzione del gestore fosse
112 arrivato un secondo segnale prima che esso abbia potuto eseguire la
113 reinstallazione di se stesso per questo secondo segnale verrebbe eseguito il
114 comportamento predefinito, il che può comportare, a seconda dei casi, la
115 perdita del segnale (se l'impostazione predefinita è quella di ignorarlo) o la
116 terminazione immediata del processo; in entrambi i casi l'azione prevista dal
117 gestore non verrebbe eseguita.
119 Questa è la ragione per cui l'implementazione dei segnali secondo questa
120 semantica viene chiamata \textsl{inaffidabile}: infatti la ricezione del
121 segnale e la reinstallazione del suo gestore non sono operazioni atomiche, e
122 sono sempre possibili delle \itindex{race~condition} \textit{race condition}
123 (si ricordi sez.~\ref{sec:proc_multi_prog}). Un altro problema è che in
124 questa semantica non esiste un modo per bloccare i segnali quando non si vuole
125 che arrivino; i processi possono ignorare il segnale, ma non è possibile
126 istruire il sistema a non fare nulla in occasione di un segnale, pur
127 mantenendo memoria del fatto che è avvenuto.
129 Nella semantica \textsl{affidabile} (quella utilizzata da Linux e da ogni Unix
130 moderno) il gestore una volta installato resta attivo e non si hanno tutti i
131 problemi precedenti. In questa semantica i segnali vengono \textsl{generati}
132 dal kernel per un processo all'occorrenza dell'evento che causa il segnale. In
133 genere questo viene fatto dal kernel impostando un apposito campo della
134 \struct{task\_struct} del processo nella \itindex{process~table}
135 \textit{process table} (si veda fig.~\ref{fig:proc_task_struct}).
137 Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
138 \textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
139 per tutto il tempo che passa fra la generazione del segnale e la sua consegna
140 esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
141 procedura viene effettuata dallo \itindex{scheduler} scheduler quando,
142 riprendendo l'esecuzione del processo in questione, verifica la presenza del
143 segnale nella \struct{task\_struct} e mette in esecuzione il gestore.
145 In questa semantica un processo ha la possibilità di bloccare la consegna dei
146 segnali, in questo caso, se l'azione per il suddetto segnale non è quella di
147 ignorarlo, il segnale resta \textsl{pendente} fintanto che il processo non lo
148 sblocca (nel qual caso viene consegnato) o imposta l'azione corrispondente per
151 Si tenga presente che il kernel stabilisce cosa fare con un segnale che è
152 stato bloccato al momento della consegna, non quando viene generato; questo
153 consente di cambiare l'azione per il segnale prima che esso venga consegnato,
154 e si può usare la funzione \func{sigpending} (vedi sez.~\ref{sec:sig_sigmask})
155 per determinare quali segnali sono bloccati e quali sono pendenti.
158 \subsection{Tipi di segnali}
159 \label{sec:sig_types}
161 In generale si tende a classificare gli eventi che possono generare dei
162 segnali in tre categorie principali: errori, eventi esterni e richieste
165 Un errore significa che un programma ha fatto qualcosa di sbagliato e non può
166 continuare ad essere eseguito. Non tutti gli errori causano dei segnali, in
167 genere le condizioni di errore più comuni comportano la restituzione di un
168 codice di errore da parte di una funzione di libreria. Sono gli errori che
169 possono avvenire nell'esecuzione delle istruzioni di un programma, come le
170 divisioni per zero o l'uso di indirizzi di memoria non validi, che causano
171 l'emissione di un segnale.
173 Un evento esterno ha in genere a che fare con le operazioni di lettura e
174 scrittura su file, o con l'interazione con dispositivi o con altri processi;
175 esempi di segnali di questo tipo sono quelli legati all'arrivo di dati in
176 ingresso, scadenze di un timer, terminazione di processi figli, la pressione
177 dei tasti di stop o di suspend su un terminale.
179 Una richiesta esplicita significa l'uso da parte di un programma delle
180 apposite funzioni di sistema (in sostanza \func{kill} o \func{raise}) per la
181 generazione ``\textsl{manuale}'' di un segnale.
183 Si dice poi che i segnali possono essere \textsl{asincroni} o
184 \textsl{sincroni}. Un segnale \textsl{sincrono} è legato ad una azione
185 specifica di un programma ed è inviato (a meno che non sia bloccato) durante
186 tale azione. Molti errori generano segnali \textsl{sincroni}, così come la
187 richiesta esplicita da parte del processo tramite le chiamate al sistema.
188 Alcuni errori come la divisione per zero non sono completamente sincroni e
189 possono arrivare dopo qualche istruzione.
191 I segnali \textsl{asincroni} sono generati da eventi fuori dal controllo del
192 processo che li riceve, e arrivano in tempi impredicibili nel corso
193 dell'esecuzione del programma. Eventi esterni come la terminazione di un
194 processo figlio generano segnali \textsl{asincroni}, così come le richieste di
195 generazione di un segnale effettuate da altri processi.
197 In generale un tipo di segnale o è sincrono o è asincrono, salvo il caso in
198 cui esso sia generato attraverso una richiesta esplicita tramite chiamata al
199 sistema, nel qual caso qualunque tipo di segnale (quello scelto nella
200 chiamata) può diventare sincrono o asincrono a seconda che sia generato
201 internamente o esternamente al processo.
204 \subsection{La notifica dei segnali}
205 \label{sec:sig_notification}
207 Come accennato quando un segnale viene generato, se la sua azione predefinita
208 non è quella di essere ignorato, il kernel prende nota del fatto nella
209 \struct{task\_struct} del processo; si dice così che il segnale diventa
210 \textsl{pendente} (o \textit{pending}), e rimane tale fino al momento in cui
211 verrà notificato al processo o verrà specificata come azione quella di
214 Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
215 avviene non appena questo viene rimesso in esecuzione dallo
216 \itindex{scheduler} scheduler che esegue l'azione specificata. Questo a meno
217 che il segnale in questione non sia stato bloccato prima della notifica, nel
218 qual caso l'invio non avviene ed il segnale resta \textsl{pendente}
221 Quando lo si sblocca un segnale \textsl{pendente} sarà subito notificato. Si
222 tenga presente però che tradizionalmente i segnali \textsl{pendenti} non si
223 accodano, alla generazione infatti il kernel marca un flag nella
224 \struct{task\_struct} del processo, per cui se prima della notifica ne vengono
225 generati altri il flag è comunque marcato, ed il gestore viene eseguito sempre
226 una sola volta. In realtà questo non vale nel caso dei cosiddetti segnali
227 \textit{real-time}, che vedremo in sez.~\ref{sec:sig_real_time}, ma questa è
228 una funzionalità avanzata che per ora tralasceremo.
230 Si ricordi inoltre che se l'azione specificata per un segnale è quella di
231 essere ignorato questo sarà scartato immediatamente al momento della sua
232 generazione, e questo anche se in quel momento il segnale è bloccato, perché
233 bloccare su un segnale significa bloccarne la notifica. Per questo motivo un
234 segnale, fintanto che viene ignorato, non sarà mai notificato, anche se prima
235 è stato bloccato ed in seguito si è specificata una azione diversa, nel qual
236 caso solo i segnali successivi alla nuova specificazione saranno notificati.
238 Una volta che un segnale viene notificato, che questo avvenga subito o dopo
239 una attesa più o meno lunga, viene eseguita l'azione specificata per il
240 segnale. Per alcuni segnali (per la precisione \signal{SIGKILL} e
241 \signal{SIGSTOP}) questa azione è predeterminata dal kernel e non può essere
242 mai modificata, ma per tutti gli altri si può selezionare una delle tre
243 possibilità seguenti:
246 \item ignorare il segnale;
247 \item intercettare il segnale, ed utilizzare il gestore specificato;
248 \item accettare l'azione predefinita per quel segnale.
251 Un programma può specificare queste scelte usando le due funzioni
252 \func{signal} e \func{sigaction}, che tratteremo rispettivamente in
253 sez.~\ref{sec:sig_signal} e sez.~\ref{sec:sig_sigaction}. Se si è installato
254 un gestore sarà quest'ultimo ad essere eseguito alla notifica del segnale.
255 Inoltre il sistema farà si che mentre viene eseguito il gestore di un segnale,
256 quest'ultimo venga automaticamente bloccato, così si possono evitare alla
257 radice possibili \itindex{race~condition} \textit{race condition}.
259 Nel caso non sia stata specificata un'azione, viene utilizzata la cosiddetta
260 azione predefinita che, come vedremo in sez.~\ref{sec:sig_standard}, è propria
261 di ciascun segnale. Nella maggior parte dei casi questa azione comporta la
262 terminazione immediata del processo, ma per alcuni segnali che rappresentano
263 eventi innocui l'azione predefinita è di essere ignorati.
265 Quando un segnale termina un processo il padre può determinare la causa della
266 terminazione esaminandone lo stato di uscita così come viene riportato dalle
267 funzioni \func{wait} e \func{waitpid} (vedi sez.~\ref{sec:proc_wait}). Questo
268 ad esempio è il modo in cui la shell determina i motivi della terminazione di
269 un programma e scrive un eventuale messaggio di errore.
271 I segnali che rappresentano errori del programma (divisione per zero o
272 violazioni di accesso) hanno come ulteriore caratteristica della loro azione
273 di default quella di scrivere un file chiamato \itindex{core~dump}
274 \textit{core dump}. Si tratta di un file binario che registra lo stato del
275 processo, ed in particolare della memoria e dello \itindex{stack}
276 \textit{stack}, prima della terminazione. Questo file può essere esaminato in
277 un secondo tempo con un apposito programma (un \textit{debugger} come
278 \cmd{gdb}) per investigare sulla causa dell'errore. Lo stesso avviene se i
279 suddetti segnali vengono generati con la funzione \func{kill}.
282 \section{La classificazione dei segnali}
283 \label{sec:sig_classification}
285 Esamineremo in questa sezione quali sono i vari segnali definiti nel sistema,
286 quali sono le loro caratteristiche e la loro tipologia, tratteremo le varie
287 macro e costanti che permettono di identificarli, e illustreremo le funzioni
288 che ne stampano la descrizione.
291 \subsection{I segnali standard}
292 \label{sec:sig_standard}
294 Ciascun segnale è identificato dal kernel con un numero, ma benché per alcuni
295 segnali questi numeri siano sempre gli stessi, tanto da essere usati come
296 sinomini, l'uso diretto degli identificativi numerici da parte dei programmi è
297 comunque da evitare, in quanto essi non sono mai stati standardizzati e
298 possono variare a seconda dell'implementazione del sistema, e nel caso di
299 Linux anche a seconda della architettura hardware e della versione del kernel.
301 Quelli che invece sono stati, almeno a grandi linee, standardizzati, sono i
302 nomi dei segnali e le costanti di preprocessore che li identificano, che sono
303 tutte nella forma \texttt{SIGnome}, e sono queste che devono essere usate nei
304 programmi. Come tutti gli altri nomi e le funzioni che concernono i segnali,
305 esse sono definite nell'header di sistema \headfile{signal.h}.
310 \begin{tabular}[c]{|l|c|c|l|}
312 \textbf{Segnale} &\textbf{Standard}&\textbf{Azione}&\textbf{Descrizione} \\
315 \signal{SIGHUP} &P & A & Hangup o terminazione del processo di
317 \signal{SIGINT} &PA& A & Interrupt da tastiera (\cmd{C-c}). \\
318 \signal{SIGQUIT} &P & C & Quit da tastiera (\cmd{C-y}). \\
319 \signal{SIGILL} &PA & C & Istruzione illecita. \\
320 \signal{SIGTRAP} &S & C & Trappole per un Trace/breakpoint. \\
321 \signal{SIGABRT} &PA & C & Segnale di abort da \func{abort}. \\
322 \signal{SIGIOT} &B & C & Trappola di I/O. Sinonimo di \signal{SIGABRT}.\\
323 \signal{SIGBUS} &S & C & Errore sul bus (bad memory access). \\
324 \signal{SIGFPE} &P & C & Errore aritmetico. \\
325 \signal{SIGKILL} &P &AEF& Segnale di terminazione forzata. \\
326 \signal{SIGUSR1} &P & A & Segnale utente numero 1. \\
327 \signal{SIGSEGV} &P & C & Errore di accesso in memoria. \\
328 \signal{SIGUSR2} &P & A & Segnale utente numero 2. \\
329 \signal{SIGPIPE} &P & A & Pipe spezzata. \\
330 \signal{SIGALRM} &P & A & Segnale del timer da \func{alarm}. \\
331 \signal{SIGTERM} &P & A & Segnale di terminazione \texttt{C-\bslash}. \\
332 \signal{SIGSTKFLT}& & A & Errore sullo stack del coprocessore. \\
333 \signal{SIGCHLD} &P & B & Figlio terminato o fermato. \\
334 \signal{SIGCONT} &P & & Continua se fermato. \\
335 \signal{SIGSTOP} &P &DEF& Ferma il processo. \\
336 \signal{SIGTSTP} &P & D & Pressione del tasto di stop sul terminale. \\
337 \signal{SIGTTIN} &P & D & Input sul terminale per un processo
339 \signal{SIGTTOU} &P & D & Output sul terminale per un processo
341 \signal{SIGURG} &SB& B & Ricezione di una \textit{urgent condition} su
343 \signal{SIGXCPU} &SB& C & Ecceduto il limite sul tempo di CPU. \\
344 \signal{SIGXFSZ} &SB& C & Ecceduto il limite sulla dimensione dei file.\\
345 \signal{SIGVTALRM}&SB& A & Timer di esecuzione scaduto. \\
346 \signal{SIGPROF} &S & A & Timer del profiling scaduto. \\
347 \signal{SIGWINCH} &B & B & Finestra ridimensionata (4.3 BSD, Sun). \\
348 \signal{SIGIO} &B & A & L'I/O è possibile (4.2 BSD). \\
349 \signal{SIGPOLL} &S & A & \textit{Pollable event} (Sys V);
350 Sinonimo di \signal{SIGIO}. \\
351 \signal{SIGPWR} & & A & Fallimento dell'alimentazione. \\
352 \signal{SIGSYS} &S & C & \textit{sistem call} sbagliata (SVID).\\
353 \signal{SIGUNUSED}& & A & Segnale inutilizzato (sinonimo di
356 \signal{SIGCLD} & & & Sinonimo di \signal{SIGCHLD}. \\
357 \signal{SIGEMT} & & & Trappola di emulatore \\
358 \signal{SIGINFO} & & & Sinonimo di \signal{SIGPWR}. \\
359 \signal{SIGLOST} &-- & & Perso un lock sul file, sinonimo
364 \caption{Lista dei segnali ordinari in Linux.}
365 \label{tab:sig_signal_list}
368 In tab.~\ref{tab:sig_signal_list} si è riportato l'elenco completo dei segnali
369 definiti su Linux per tutte le possibili architetture. Ma si tenga presente
370 che alcuni di questi (quelli nella sezione finale della tabella) non esistono
371 sull'architettura PC, ma sono definiti sulle architetture \textit{alpha} o
374 Dato che alcuni segnali erano previsti fin dallo standard ANSI C, e che i
375 segnali sono presenti in tutti i sistemi unix-like, con differenze dovute alle
376 implementazioni ed all'uso degli stessi la seconda colonna della tabella
377 riporta con altrettante lettere gli standard in cui ciascun segnale è stato
378 definito, da interpretare secondo la legenda di
379 tab.~\ref{tab:sig_standard_leg}.
384 \begin{tabular}[c]{|c|l|}
386 \textbf{Sigla} & \textbf{Standard} \\
390 B & BSD (4.2 BSD e Sun)\\
392 S & SUSv2 (e POSIX.1-2001)\\
396 \caption{Legenda dei valori degli standard riportati nella seconda colonna
397 di tab.~\ref{tab:sig_signal_list}.}
398 \label{tab:sig_standard_leg}
402 Come accennato in sez.~\ref{sec:sig_notification} a ciascun segnale è
403 associata una specifica azione predefinita che viene eseguita quando nessun
404 gestore è installato. Anche queste sono riportate in
405 tab.~\ref{tab:sig_signal_list} nella terza colonna, di nuovo identificate con
406 delle lettere, la cui legenda completa è illustrate in
407 tab.~\ref{tab:sig_action_leg}). Nella stessa colonna si sono indicate anche,
408 le condizioni specifiche dei segnali che non possono essere intercettati o
411 Si noti come \const{SIGCONT} sia l'unico segnale a non avere una
412 azione predefinita, in quanto il suo unico effetto è quello di far ripartire
413 un programma fermato da un segnale di stop.
415 In alcuni casi alla terminazione del processo è associata la creazione di un
416 file (posto nella directory corrente del processo e chiamato \file{core}) su
417 cui viene salvata un'immagine della memoria del processo (il cosiddetto
418 \itindex{core~dump} \textit{core dump}), che può essere usata da un debugger
419 per esaminare lo stato dello \itindex{stack} \textit{stack} e delle variabili
420 al momento della ricezione del segnale.
426 \begin{tabular}[c]{|c|l|}
428 \textbf{Sigla} & \textbf{Significato} \\
431 A & L'azione predefinita è terminare il processo.\\
432 B & L'azione predefinita è ignorare il segnale.\\
433 C & L'azione predefinita è terminare il processo e scrivere un
434 \itindex{core~dump} \textit{core dump}.\\
435 D & L'azione predefinita è fermare il processo.\\
436 E & Il segnale non può essere intercettato.\\
437 F & Il segnale non può essere ignorato.\\
440 \caption{Legenda delle azioni predefinite dei segnali riportate nella terza
441 colonna di tab.~\ref{tab:sig_signal_list}.}
442 \label{tab:sig_action_leg}
446 Il numero totale di segnali presenti è dato dalla macro \const{NSIG}, e dato
447 che i numeri dei segnali sono allocati progressivamente, essa corrisponde
448 anche al successivo del valore numerico assegnato all'ultimo segnale definito.
450 La descrizione dettagliata del significato dei vari segnali, raggruppati per
451 tipologia, verrà affrontata nei paragrafi successivi.
454 \subsection{Segnali di errore di programma}
455 \label{sec:sig_prog_error}
457 Questi segnali sono generati quando il sistema, o in certi casi direttamente
458 l'hardware (come per i \itindex{page~fault} \textit{page fault} non validi)
459 rileva un qualche errore insanabile nel programma in esecuzione. In generale
460 la generazione di questi segnali significa che il programma ha dei gravi
461 problemi (ad esempio ha dereferenziato un puntatore non valido o ha eseguito
462 una operazione aritmetica proibita) e l'esecuzione non può essere proseguita.
464 In genere si intercettano questi segnali per permettere al programma di
465 terminare in maniera pulita, ad esempio per ripristinare le impostazioni della
466 console o eliminare i \index{file!di lock} file di lock prima dell'uscita. In
467 questo caso il gestore deve concludersi ripristinando l'azione predefinita e
468 rialzando il segnale, in questo modo il programma si concluderà senza effetti
469 spiacevoli, ma riportando lo stesso stato di uscita che avrebbe avuto se il
470 gestore non ci fosse stato.
472 L'azione predefinita per tutti questi segnali è causare la terminazione del
473 processo che li ha causati. In genere oltre a questo il segnale provoca pure
474 la registrazione su disco di un file di \itindex{core~dump} \textit{core dump}
475 che viene scritto in un file \file{core} nella directory corrente del processo
476 al momento dell'errore, che il debugger può usare per ricostruire lo stato del
477 programma al momento della terminazione. Questi segnali sono:
478 \begin{basedescript}{\desclabelwidth{2.0cm}}
479 \item[\signal{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome
480 derivi da \textit{floating point exception} si applica a tutti gli errori
481 aritmetici compresa la divisione per zero e l'overflow. Se il gestore
482 ritorna il comportamento del processo è indefinito, ed ignorare questo
483 segnale può condurre ad un ciclo infinito.
485 % Per questo segnale le cose sono complicate dal fatto che possono esserci
486 % molte diverse eccezioni che \signal{SIGFPE} non distingue, mentre lo
487 % standard IEEE per le operazioni in virgola mobile definisce varie eccezioni
488 % aritmetiche e richiede che esse siano notificate.
489 % TODO trovare altre info su SIGFPE e trattare la notifica delle eccezioni
491 \item[\signal{SIGILL}] Il nome deriva da \textit{illegal instruction},
492 significa che il programma sta cercando di eseguire una istruzione
493 privilegiata o inesistente, in generale del codice illecito. Poiché il
494 compilatore del C genera del codice valido si ottiene questo segnale se il
495 file eseguibile è corrotto o si stanno cercando di eseguire dei dati.
496 Quest'ultimo caso può accadere quando si passa un puntatore sbagliato al
497 posto di un puntatore a funzione, o si eccede la scrittura di un vettore di
498 una variabile locale, andando a corrompere lo \itindex{stack}
499 \textit{stack}. Lo stesso segnale viene generato in caso di overflow dello
500 \itindex{stack} \textit{stack} o di problemi nell'esecuzione di un gestore.
501 Se il gestore ritorna il comportamento del processo è indefinito.
502 \item[\signal{SIGSEGV}] Il nome deriva da \itindex{segment~violation}
503 \textit{segment violation}, e significa che il programma sta cercando di
504 leggere o scrivere in una zona di memoria protetta al di fuori di quella che
505 gli è stata riservata dal sistema. In genere è il meccanismo della
506 protezione della memoria che si accorge dell'errore ed il kernel genera il
507 segnale. Se il gestore ritorna il comportamento del processo è indefinito.
509 È tipico ottenere questo segnale dereferenziando un puntatore nullo o non
510 inizializzato leggendo al di là della fine di un vettore.
511 \item[\signal{SIGBUS}] Il nome deriva da \textit{bus error}. Come
512 \signal{SIGSEGV} questo è un segnale che viene generato di solito quando si
513 dereferenzia un puntatore non inizializzato, la differenza è che
514 \signal{SIGSEGV} indica un accesso non permesso su un indirizzo esistente
515 (tipo fuori dallo heap o dallo \itindex{stack} \textit{stack}), mentre
516 \signal{SIGBUS} indica l'accesso ad un indirizzo non valido, come nel caso di
517 un puntatore non allineato.
518 \item[\signal{SIGABRT}] Il nome deriva da \textit{abort}. Il segnale indica che
519 il programma stesso ha rilevato un errore che viene riportato chiamando la
520 funzione \func{abort} che genera questo segnale.
521 \item[\signal{SIGTRAP}] È il segnale generato da un'istruzione di breakpoint o
522 dall'attivazione del tracciamento per il processo. È usato dai programmi per
523 il debugging e un programma normale non dovrebbe ricevere questo segnale.
524 \item[\signal{SIGSYS}] Sta ad indicare che si è eseguita una istruzione che
525 richiede l'esecuzione di una system call, ma si è fornito un codice
526 sbagliato per quest'ultima.
530 \subsection{I segnali di terminazione}
531 \label{sec:sig_termination}
533 Questo tipo di segnali sono usati per terminare un processo; hanno vari nomi a
534 causa del differente uso che se ne può fare, ed i programmi possono
535 trattarli in maniera differente.
537 La ragione per cui può essere necessario trattare questi segnali è che il
538 programma può dover eseguire una serie di azioni di pulizia prima di
539 terminare, come salvare informazioni sullo stato in cui si trova, cancellare
540 file temporanei, o ripristinare delle condizioni alterate durante il
541 funzionamento (come il modo del terminale o le impostazioni di una qualche
544 L'azione predefinita di questi segnali è di terminare il processo, questi
546 \begin{basedescript}{\desclabelwidth{2.0cm}}
547 \item[\signal{SIGTERM}] Il nome sta per \textit{terminate}. È un segnale
548 generico usato per causare la conclusione di un programma. Al contrario di
549 \signal{SIGKILL} può essere intercettato, ignorato, bloccato. In genere lo si
550 usa per chiedere in maniera ``\textsl{educata}'' ad un processo di
553 \item[\signal{SIGINT}] Il nome sta per \textit{interrupt}. È il segnale di
554 interruzione per il programma. È quello che viene generato di default dal
555 comando \cmd{kill} o dall'invio sul terminale del carattere di controllo
556 INTR (interrupt, generato dalla sequenza \cmd{C-c}).
558 \item[\signal{SIGQUIT}] È analogo a \signal{SIGINT} con la differenza che è
559 controllato da un altro carattere di controllo, QUIT, corrispondente alla
560 sequenza \texttt{C-\bslash}. A differenza del precedente l'azione
561 predefinita, oltre alla terminazione del processo, comporta anche la
562 creazione di un \itindex{core~dump} \textit{core dump}.
564 In genere lo si può pensare come corrispondente ad una condizione di errore
565 del programma rilevata dall'utente. Per questo motivo non è opportuno fare
566 eseguire al gestore di questo segnale le operazioni di pulizia normalmente
567 previste (tipo la cancellazione di file temporanei), dato che in certi casi
568 esse possono eliminare informazioni utili nell'esame dei \itindex{core~dump}
572 \item[\signal{SIGKILL}] Il nome è utilizzato per terminare in maniera immediata
573 qualunque programma. Questo segnale non può essere né intercettato, né
574 ignorato, né bloccato, per cui causa comunque la terminazione del processo.
575 In genere esso viene generato solo per richiesta esplicita dell'utente dal
576 comando (o tramite la funzione) \cmd{kill}. Dato che non lo si può
577 intercettare è sempre meglio usarlo come ultima risorsa quando metodi meno
578 brutali, come \signal{SIGTERM} o \cmd{C-c} non funzionano.
580 Se un processo non risponde a nessun altro segnale \signal{SIGKILL} ne causa
581 sempre la terminazione (in effetti il fallimento della terminazione di un
582 processo da parte di \signal{SIGKILL} costituirebbe un malfunzionamento del
583 kernel). Talvolta è il sistema stesso che può generare questo segnale quando
584 per condizioni particolari il processo non può più essere eseguito neanche
585 per eseguire un gestore.
587 \item[\signal{SIGHUP}] Il nome sta per \textit{hang-up}. Segnala che il
588 terminale dell'utente si è disconnesso (ad esempio perché si è interrotta la
589 rete). Viene usato anche per riportare la terminazione del processo di
590 controllo di un terminale a tutti i processi della sessione, in modo che
591 essi possano disconnettersi dal relativo terminale.
593 Viene inoltre usato in genere per segnalare ai demoni (che non hanno un
594 terminale di controllo) la necessità di reinizializzarsi e rileggere il/i
595 file di configurazione.
599 \subsection{I segnali di allarme}
600 \label{sec:sig_alarm}
602 Questi segnali sono generati dalla scadenza di un timer (vedi
603 sez.~\ref{sec:sig_alarm_abort}). Il loro comportamento predefinito è quello di
604 causare la terminazione del programma, ma con questi segnali la scelta
605 predefinita è irrilevante, in quanto il loro uso presuppone sempre la
606 necessità di un gestore. Questi segnali sono:
607 \begin{basedescript}{\desclabelwidth{2.0cm}}
608 \item[\signal{SIGALRM}] Il nome sta per \textit{alarm}. Segnale la scadenza di
609 un timer misurato sul tempo reale o sull'orologio di sistema. È normalmente
610 usato dalla funzione \func{alarm}.
612 \item[\const{SIVGTALRM}] Il nome sta per \textit{virtual alarm}. È analogo al
613 precedente ma segnala la scadenza di un timer sul tempo di CPU usato dal
616 \item[\signal{SIGPROF}] Il nome sta per \textit{profiling}. Indica la scadenza
617 di un timer che misura sia il tempo di CPU speso direttamente dal processo
618 che quello che il sistema ha speso per conto di quest'ultimo. In genere
619 viene usato dagli strumenti che servono a fare la profilazione dell'utilizzo
620 del tempo di CPU da parte del processo.
624 \subsection{I segnali di I/O asincrono}
625 \label{sec:sig_asyncio}
627 Questi segnali operano in congiunzione con le funzioni di I/O asincrono. Per
628 questo occorre comunque usare \func{fcntl} per abilitare un file descriptor a
629 generare questi segnali. L'azione predefinita è di essere ignorati. Questi
631 \begin{basedescript}{\desclabelwidth{2.0cm}}
632 \item[\signal{SIGIO}] Questo segnale viene inviato quando un file descriptor è
633 pronto per eseguire dell'input/output. In molti sistemi solo i
634 socket e i terminali possono generare questo segnale, in Linux
635 questo può essere usato anche per i file, posto che la \func{fcntl} abbia
638 \item[\signal{SIGURG}] Questo segnale è inviato quando arrivano dei dati
639 urgenti o \itindex{out-of-band} \textit{out-of-band} su di un
640 socket; per maggiori dettagli al proposito si veda
641 sez.~\ref{sec:TCP_urgent_data}.
643 \item[\signal{SIGPOLL}] Questo segnale è equivalente a \signal{SIGIO}, è
644 definito solo per compatibilità con i sistemi System V.
648 \subsection{I segnali per il controllo di sessione}
649 \label{sec:sig_job_control}
651 Questi sono i segnali usati dal controllo delle sessioni e dei processi, il
652 loro uso è specializzato e viene trattato in maniera specifica nelle sezioni
653 in cui si trattano gli argomenti relativi. Questi segnali sono:
654 \begin{basedescript}{\desclabelwidth{2.0cm}}
655 \item[\signal{SIGCHLD}] Questo è il segnale mandato al processo padre quando un
656 figlio termina o viene fermato. L'azione predefinita è di ignorare il
657 segnale, la sua gestione è trattata in sez.~\ref{sec:proc_wait}.
659 \item[\signal{SIGCLD}] Per Linux questo è solo un segnale identico al
660 precedente, il nome è obsoleto e andrebbe evitato.
662 \item[\signal{SIGCONT}] Il nome sta per \textit{continue}. Il segnale viene
663 usato per fare ripartire un programma precedentemente fermato da
664 \signal{SIGSTOP}. Questo segnale ha un comportamento speciale, e fa sempre
665 ripartire il processo prima della sua consegna. Il comportamento predefinito
666 è di fare solo questo; il segnale non può essere bloccato. Si può anche
667 installare un gestore, ma il segnale provoca comunque il riavvio del
670 La maggior pare dei programmi non hanno necessità di intercettare il
671 segnale, in quanto esso è completamente trasparente rispetto all'esecuzione
672 che riparte senza che il programma noti niente. Si possono installare dei
673 gestori per far si che un programma produca una qualche azione speciale
674 se viene fermato e riavviato, come per esempio riscrivere un prompt, o
676 \item[\signal{SIGSTOP}] Il segnale ferma un processo (lo porta cioè in uno
677 stato di sleep, vedi sez.~\ref{sec:proc_sched}); il segnale non può essere né
678 intercettato, né ignorato, né bloccato.
680 \item[\signal{SIGTSTP}] Il nome sta per \textit{interactive stop}. Il segnale
681 ferma il processo interattivamente, ed è generato dal carattere SUSP
682 (prodotto dalla combinazione \cmd{C-z}), ed al contrario di
683 \signal{SIGSTOP} può essere intercettato e ignorato. In genere un programma
684 installa un gestore per questo segnale quando vuole lasciare il sistema
685 o il terminale in uno stato definito prima di fermarsi; se per esempio un
686 programma ha disabilitato l'eco sul terminale può installare un gestore
687 per riabilitarlo prima di fermarsi.
689 \item[\signal{SIGTTIN}] Un processo non può leggere dal terminale se esegue una
690 sessione di lavoro in \textit{background}. Quando un processo in background
691 tenta di leggere da un terminale viene inviato questo segnale a tutti i
692 processi della sessione di lavoro. L'azione predefinita è di fermare il
693 processo. L'argomento è trattato in
694 sez.~\ref{sec:sess_job_control_overview}.
696 \item[\signal{SIGTTOU}] Segnale analogo al precedente \signal{SIGTTIN}, ma
697 generato quando si tenta di scrivere o modificare uno dei modi del
698 terminale. L'azione predefinita è di fermare il processo, l'argomento è
699 trattato in sez.~\ref{sec:sess_job_control_overview}.
703 \subsection{I segnali di operazioni errate}
704 \label{sec:sig_oper_error}
706 Questi segnali sono usati per riportare al programma errori generati da
707 operazioni da lui eseguite; non indicano errori del programma quanto errori
708 che impediscono il completamento dell'esecuzione dovute all'interazione con il
709 resto del sistema. L'azione predefinita di questi segnali è di terminare il
710 processo, questi segnali sono:
711 \begin{basedescript}{\desclabelwidth{2.0cm}}
712 \item[\signal{SIGPIPE}] Sta per \textit{Broken pipe}. Se si usano delle pipe,
713 (o delle FIFO o dei socket) è necessario, prima che un processo inizi a
714 scrivere su una di esse, che un altro l'abbia aperta in lettura (si veda
715 sez.~\ref{sec:ipc_pipes}). Se il processo in lettura non è partito o è
716 terminato inavvertitamente alla scrittura sulla pipe il kernel genera questo
717 segnale. Se il segnale è bloccato, intercettato o ignorato la chiamata che
718 lo ha causato fallisce, restituendo l'errore \errcode{EPIPE}.
719 \item[\signal{SIGLOST}] Sta per \textit{Resource lost}. Tradizionalmente è il
720 segnale che viene generato quando si perde un advisory lock su un file su
721 NFS perché il server NFS è stato riavviato. Il progetto GNU lo utilizza per
722 indicare ad un client il crollo inaspettato di un server. In Linux è
723 definito come sinonimo di \signal{SIGIO}.\footnote{ed è segnalato come BUG
724 nella pagina di manuale.}
725 \item[\signal{SIGXCPU}] Sta per \textit{CPU time limit exceeded}. Questo
726 segnale è generato quando un processo eccede il limite impostato per il
727 tempo di CPU disponibile, vedi sez.~\ref{sec:sys_resource_limit}.
728 \item[\signal{SIGXFSZ}] Sta per \textit{File size limit exceeded}. Questo
729 segnale è generato quando un processo tenta di estendere un file oltre le
730 dimensioni specificate dal limite impostato per le dimensioni massime di un
731 file, vedi sez.~\ref{sec:sys_resource_limit}.
735 \subsection{Ulteriori segnali}
736 \label{sec:sig_misc_sig}
738 Raccogliamo qui infine una serie di segnali che hanno scopi differenti non
739 classificabili in maniera omogenea. Questi segnali sono:
740 \begin{basedescript}{\desclabelwidth{2.0cm}}
741 \item[\signal{SIGUSR1}] Insieme a \signal{SIGUSR2} è un segnale a disposizione
742 dell'utente che lo può usare per quello che vuole. Viene generato solo
743 attraverso l'invocazione della funzione \func{kill}. Entrambi i segnali
744 possono essere utili per implementare una comunicazione elementare fra
745 processi diversi, o per eseguire a richiesta una operazione utilizzando un
746 gestore. L'azione predefinita è di terminare il processo.
747 \item[\signal{SIGUSR2}] È il secondo segnale a disposizione degli utenti. Vedi
748 quanto appena detto per \signal{SIGUSR1}.
749 \item[\signal{SIGWINCH}] Il nome sta per \textit{window (size) change} e viene
750 generato in molti sistemi (GNU/Linux compreso) quando le dimensioni (in
751 righe e colonne) di un terminale vengono cambiate. Viene usato da alcuni
752 programmi testuali per riformattare l'uscita su schermo quando si cambia
753 dimensione a quest'ultimo. L'azione predefinita è di essere ignorato.
754 \item[\signal{SIGINFO}] Il segnale indica una richiesta di informazioni. È
755 usato con il controllo di sessione, causa la stampa di informazioni da parte
756 del processo leader del gruppo associato al terminale di controllo, gli
757 altri processi lo ignorano.
761 \subsection{Le funzioni \func{strsignal} e \func{psignal}}
762 \label{sec:sig_strsignal}
764 Per la descrizione dei segnali il sistema mette a disposizione due funzioni
765 che stampano un messaggio di descrizione dato il numero. In genere si usano
766 quando si vuole notificare all'utente il segnale ricevuto (nel caso di
767 terminazione di un processo figlio o di un gestore che gestisce più segnali);
768 la prima funzione, \funcd{strsignal}, è una estensione GNU, accessibile avendo
769 definito \macro{\_GNU\_SOURCE}, ed è analoga alla funzione \func{strerror} (si
770 veda sez.~\ref{sec:sys_strerror}) per gli errori:
771 \begin{prototype}{string.h}{char *strsignal(int signum)}
772 Ritorna il puntatore ad una stringa che contiene la descrizione del segnale
775 \noindent dato che la stringa è allocata staticamente non se ne deve
776 modificare il contenuto, che resta valido solo fino alla successiva chiamata
777 di \func{strsignal}. Nel caso si debba mantenere traccia del messaggio sarà
780 La seconda funzione, \funcd{psignal}, deriva da BSD ed è analoga alla funzione
781 \func{perror} descritta sempre in sez.~\ref{sec:sys_strerror}; il suo prototipo
783 \begin{prototype}{signal.h}{void psignal(int sig, const char *s)}
784 Stampa sullo standard error un messaggio costituito dalla stringa \param{s},
785 seguita da due punti ed una descrizione del segnale indicato da \param{sig}.
788 Una modalità alternativa per utilizzare le descrizioni restituite da
789 \func{strsignal} e \func{psignal} è quello di usare la variabile
790 \var{sys\_siglist}, che è definita in \headfile{signal.h} e può essere
791 acceduta con la dichiarazione:
792 \includecodesnip{listati/siglist.c}
794 L'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
795 indicizzate per numero di segnale, per cui una chiamata del tipo di \code{char
796 *decr = strsignal(SIGINT)} può essere sostituita dall'equivalente \code{char
797 *decr = sys\_siglist[SIGINT]}.
801 \section{La gestione di base dei segnali}
802 \label{sec:sig_management}
804 I segnali sono il primo e più classico esempio di eventi asincroni, cioè di
805 eventi che possono accadere in un qualunque momento durante l'esecuzione di un
806 programma. Per questa loro caratteristica la loro gestione non può essere
807 effettuata all'interno del normale flusso di esecuzione dello stesso, ma è
808 delegata appunto agli eventuali gestori che si sono installati.
810 In questa sezione vedremo come si effettua la gestione dei segnali, a partire
811 dalla loro interazione con le system call, passando per le varie funzioni che
812 permettono di installare i gestori e controllare le reazioni di un processo
813 alla loro occorrenza.
816 \subsection{Il comportamento generale del sistema}
817 \label{sec:sig_gen_beha}
819 Abbiamo già trattato in sez.~\ref{sec:sig_intro} le modalità con cui il sistema
820 gestisce l'interazione fra segnali e processi, ci resta da esaminare però il
821 comportamento delle system call; in particolare due di esse, \func{fork} ed
822 \func{exec}, dovranno essere prese esplicitamente in considerazione, data la
823 loro stretta relazione con la creazione di nuovi processi.
825 Come accennato in sez.~\ref{sec:proc_fork} quando viene creato un nuovo
826 processo esso eredita dal padre sia le azioni che sono state impostate per i
827 singoli segnali, che la maschera dei segnali bloccati (vedi
828 sez.~\ref{sec:sig_sigmask}). Invece tutti i segnali pendenti e gli allarmi
829 vengono cancellati; essi infatti devono essere recapitati solo al padre, al
830 figlio dovranno arrivare solo i segnali dovuti alle sue azioni.
832 Quando si mette in esecuzione un nuovo programma con \func{exec} (si ricordi
833 quanto detto in sez.~\ref{sec:proc_exec}) tutti i segnali per i quali è stato
834 installato un gestore vengono reimpostati a \const{SIG\_DFL}. Non ha più
835 senso infatti fare riferimento a funzioni definite nel programma originario,
836 che non sono presenti nello spazio di indirizzi del nuovo programma.
838 Si noti che questo vale solo per le azioni per le quali è stato installato un
839 gestore; viene mantenuto invece ogni eventuale impostazione dell'azione a
840 \const{SIG\_IGN}. Questo permette ad esempio alla shell di impostare ad
841 \const{SIG\_IGN} le risposte per \signal{SIGINT} e \signal{SIGQUIT} per i
842 programmi eseguiti in background, che altrimenti sarebbero interrotti da una
843 successiva pressione di \texttt{C-c} o \texttt{C-y}.
845 Per quanto riguarda il comportamento di tutte le altre \textit{system call} si
846 danno sostanzialmente due casi, a seconda che esse siano
847 \index{system~call~lente} \textsl{lente} (\textit{slow}) o \textsl{veloci}
848 (\textit{fast}). La gran parte di esse appartiene a quest'ultima categoria,
849 che non è influenzata dall'arrivo di un segnale. Esse sono dette
850 \textsl{veloci} in quanto la loro esecuzione è sostanzialmente immediata; la
851 risposta al segnale viene sempre data dopo che la \textit{system call} è stata
852 completata, in quanto attendere per eseguire un gestore non comporta nessun
855 In alcuni casi però alcune system call (che per questo motivo vengono chiamate
856 \textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può
857 attendere la conclusione della system call, perché questo renderebbe
858 impossibile una risposta pronta al segnale, per cui il gestore viene
859 eseguito prima che la system call sia ritornata. Un elenco dei casi in cui si
860 presenta questa situazione è il seguente:
862 \item la lettura da file che possono bloccarsi in attesa di dati non ancora
863 presenti (come per certi \index{file!di~dispositivo} file di dispositivo, i
865 \item la scrittura sugli stessi file, nel caso in cui dati non possano essere
866 accettati immediatamente (di nuovo comune per i socket);
867 \item l'apertura di un file di dispositivo che richiede operazioni non
868 immediate per una risposta (ad esempio l'apertura di un nastro che deve
870 \item le operazioni eseguite con \func{ioctl} che non è detto possano essere
871 eseguite immediatamente;
872 \item le funzioni di intercomunicazione che si bloccano in attesa di risposte
874 \item la funzione \func{pause} (usata appunto per attendere l'arrivo di un
876 \item la funzione \func{wait} (se nessun processo figlio è ancora terminato).
879 In questo caso si pone il problema di cosa fare una volta che il gestore sia
880 ritornato. La scelta originaria dei primi Unix era quella di far ritornare
881 anche la system call restituendo l'errore di \errcode{EINTR}. Questa è a
882 tutt'oggi una scelta corrente, ma comporta che i programmi che usano dei
883 gestori controllino lo stato di uscita delle funzioni che eseguono una system
884 call lenta per ripeterne la chiamata qualora l'errore fosse questo.
886 Dimenticarsi di richiamare una system call interrotta da un segnale è un
887 errore comune, tanto che le \acr{glibc} provvedono una macro
888 \code{TEMP\_FAILURE\_RETRY(expr)} che esegue l'operazione automaticamente,
889 ripetendo l'esecuzione dell'espressione \var{expr} fintanto che il risultato
890 non è diverso dall'uscita con un errore \errcode{EINTR}.
892 La soluzione è comunque poco elegante e BSD ha scelto un approccio molto
893 diverso, che è quello di fare ripartire automaticamente una system call
894 interrotta invece di farla fallire. In questo caso ovviamente non c'è bisogno
895 di preoccuparsi di controllare il codice di errore; si perde però la
896 possibilità di eseguire azioni specifiche all'occorrenza di questa particolare
899 Linux e le \acr{glibc} consentono di utilizzare entrambi gli approcci,
900 attraverso una opportuna opzione di \func{sigaction} (vedi
901 sez.~\ref{sec:sig_sigaction}). È da chiarire comunque che nel caso di
902 interruzione nel mezzo di un trasferimento parziale di dati, le system call
903 ritornano sempre indicando i byte trasferiti.
905 % TODO: alcune syscall danno EINTR anche se il segnale è installato con
906 % SA_RESTART, vedi signal(7)
909 \subsection{La funzione \func{signal}}
910 \label{sec:sig_signal}
912 L'interfaccia più semplice per la gestione dei segnali è costituita dalla
913 funzione \funcd{signal} che è definita fin dallo standard ANSI C.
914 Quest'ultimo però non considera sistemi multitasking, per cui la definizione è
915 tanto vaga da essere del tutto inutile in un sistema Unix; è questo il motivo
916 per cui ogni implementazione successiva ne ha modificato e ridefinito il
917 comportamento, pur mantenendone immutato il prototipo\footnote{in realtà in
918 alcune vecchie implementazioni (SVr4 e 4.3+BSD in particolare) vengono usati
919 alcuni argomenti aggiuntivi per definire il comportamento della funzione,
920 vedremo in sez.~\ref{sec:sig_sigaction} che questo è possibile usando la
921 funzione \func{sigaction}.} che è:
922 \begin{prototype}{signal.h}
923 {sighandler\_t signal(int signum, sighandler\_t handler)}
925 Installa la funzione di gestione \param{handler} (il gestore) per il
926 segnale \param{signum}.
928 \bodydesc{La funzione ritorna il precedente gestore in caso di successo
929 o \const{SIG\_ERR} in caso di errore.}
932 In questa definizione si è usato un tipo di dato, \type{sighandler\_t}, che è
933 una estensione GNU, definita dalle \acr{glibc}, che permette di riscrivere il
934 prototipo di \func{signal} nella forma appena vista, molto più leggibile di
935 quanto non sia la versione originaria, che di norma è definita come:
936 \includecodesnip{listati/signal.c}
937 questa infatti, per la poca chiarezza della sintassi del C quando si vanno a
938 trattare puntatori a funzioni, è molto meno comprensibile. Da un confronto
939 con il precedente prototipo si può dedurre la definizione di
940 \type{sighandler\_t} che è:
941 \includecodesnip{listati/sighandler_t.c}
942 e cioè un puntatore ad una funzione \ctyp{void} (cioè senza valore di ritorno)
943 e che prende un argomento di tipo \ctyp{int}.\footnote{si devono usare le
944 parentesi intorno al nome della funzione per via delle precedenze degli
945 operatori del C, senza di esse si sarebbe definita una funzione che ritorna
946 un puntatore a \ctyp{void} e non un puntatore ad una funzione \ctyp{void}.}
947 La funzione \func{signal} quindi restituisce e prende come secondo argomento
948 un puntatore a una funzione di questo tipo, che è appunto la funzione che
949 verrà usata come gestore del segnale.
951 Il numero di segnale passato nell'argomento \param{signum} può essere indicato
952 direttamente con una delle costanti definite in sez.~\ref{sec:sig_standard}.
953 L'argomento \param{handler} che indica il gestore invece, oltre all'indirizzo
954 della funzione da chiamare all'occorrenza del segnale, può assumere anche i
955 due valori costanti \const{SIG\_IGN} e \const{SIG\_DFL}; il primo indica che
956 il segnale deve essere ignorato,\footnote{si ricordi però che i due segnali
957 \signal{SIGKILL} e \signal{SIGSTOP} non possono essere né ignorati né
958 intercettati; l'uso di \const{SIG\_IGN} per questi segnali non ha alcun
959 effetto.} mentre il secondo ripristina l'azione predefinita.\footnote{e
960 serve a tornare al comportamento di default quando non si intende più
961 gestire direttamente un segnale.}
963 La funzione restituisce l'indirizzo dell'azione precedente, che può essere
964 salvato per poterlo ripristinare (con un'altra chiamata a \func{signal}) in un
965 secondo tempo. Si ricordi che se si imposta come azione \const{SIG\_IGN} (o si
966 imposta un \const{SIG\_DFL} per un segnale la cui azione predefinita è di
967 essere ignorato), tutti i segnali pendenti saranno scartati, e non verranno
970 L'uso di \func{signal} è soggetto a problemi di compatibilità, dato che essa
971 si comporta in maniera diversa per sistemi derivati da BSD o da System V. In
972 questi ultimi infatti la funzione è conforme al comportamento originale dei
973 primi Unix in cui il gestore viene disinstallato alla sua chiamata, secondo la
974 semantica inaffidabile; anche Linux seguiva questa convenzione con le vecchie
975 librerie del C come le \acr{libc4} e le \acr{libc5}.\footnote{nelle
976 \acr{libc5} esiste però la possibilità di includere \file{bsd/signal.h} al
977 posto di \headfile{signal.h}, nel qual caso la funzione \func{signal} viene
978 ridefinita per seguire la semantica affidabile usata da BSD.}
980 Al contrario BSD segue la semantica affidabile, non disinstallando il gestore
981 e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo delle
982 \acr{glibc} dalla versione 2 anche Linux è passato a questo comportamento. Il
983 comportamento della versione originale della funzione, il cui uso è deprecato
984 per i motivi visti in sez.~\ref{sec:sig_semantics}, può essere ottenuto
985 chiamando \funcm{sysv\_signal}, una volta che si sia definita la macro
986 \macro{\_XOPEN\_SOURCE}. In generale, per evitare questi problemi, l'uso di
987 \func{signal}, che tra l'altro ha un comportamento indefinito in caso di
988 processo \itindex{thread} multi-\textit{thread}, è da evitare; tutti i nuovi
989 programmi dovrebbero usare \func{sigaction}.
991 È da tenere presente che, seguendo lo standard POSIX, il comportamento di un
992 processo che ignora i segnali \signal{SIGFPE}, \signal{SIGILL}, o
993 \signal{SIGSEGV} (qualora questi non originino da una chiamata ad una
994 \func{kill} o ad una \func{raise}) è indefinito. Un gestore che ritorna da
995 questi segnali può dare luogo ad un ciclo infinito.
998 \subsection{Le funzioni \func{kill} e \func{raise}}
999 \label{sec:sig_kill_raise}
1001 Come precedentemente accennato in sez.~\ref{sec:sig_types}, un segnale può
1002 anche essere generato direttamente nell'esecuzione di un programma, attraverso
1003 la chiamata ad una opportuna system call. Le funzioni che si utilizzano di
1004 solito per inviare un segnale generico ad un processo sono due: \func{raise} e
1007 La prima funzione è \funcd{raise}, che è definita dallo standard ANSI C, e
1008 serve per inviare un segnale al processo corrente,\footnote{non prevedendo la
1009 presenza di un sistema multiutente lo standard ANSI C non poteva che
1010 definire una funzione che invia il segnale al programma in esecuzione. Nel
1011 caso di Linux questa viene implementata come funzione di compatibilità.} il
1013 \begin{prototype}{signal.h}{int raise(int sig)}
1014 Invia il segnale \param{sig} al processo corrente.
1016 \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
1017 errore, il solo errore restituito è \errval{EINVAL} qualora si sia
1018 specificato un numero di segnale invalido.}
1021 Il valore di \param{sig} specifica il segnale che si vuole inviare e può
1022 essere specificato con una delle macro definite in
1023 sez.~\ref{sec:sig_classification}. In genere questa funzione viene usata per
1024 riprodurre il comportamento predefinito di un segnale che sia stato
1025 intercettato. In questo caso, una volta eseguite le operazioni volute, il
1026 gestore dovrà prima reinstallare l'azione predefinita, per poi attivarla
1027 chiamando \func{raise}.
1029 Mentre \func{raise} è una funzione di libreria, quando si vuole inviare un
1030 segnale generico ad un processo occorre utilizzare la apposita system call,
1031 questa può essere chiamata attraverso la funzione \funcd{kill}, il cui
1034 \headdecl{sys/types.h}
1036 \funcdecl{int kill(pid\_t pid, int sig)} Invia il segnale \param{sig} al
1037 processo specificato con \param{pid}.
1039 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
1040 errore nel qual caso \var{errno} assumerà uno dei valori:
1042 \item[\errcode{EINVAL}] il segnale specificato non esiste.
1043 \item[\errcode{ESRCH}] il processo selezionato non esiste.
1044 \item[\errcode{EPERM}] non si hanno privilegi sufficienti ad inviare il
1049 Lo standard POSIX prevede che il valore 0 per \param{sig} sia usato per
1050 specificare il segnale nullo. Se la funzione viene chiamata con questo valore
1051 non viene inviato nessun segnale, ma viene eseguito il controllo degli errori,
1052 in tal caso si otterrà un errore \errcode{EPERM} se non si hanno i permessi
1053 necessari ed un errore \errcode{ESRCH} se il processo specificato non esiste.
1054 Si tenga conto però che il sistema ricicla i \ids{PID} (come accennato in
1055 sez.~\ref{sec:proc_pid}) per cui l'esistenza di un processo non significa che
1056 esso sia realmente quello a cui si intendeva mandare il segnale.
1058 Il valore dell'argomento \param{pid} specifica il processo (o i processi) di
1059 destinazione a cui il segnale deve essere inviato e può assumere i valori
1060 riportati in tab.~\ref{tab:sig_kill_values}.
1062 Si noti pertanto che la funzione \code{raise(sig)} può essere definita in
1063 termini di \func{kill}, ed è sostanzialmente equivalente ad una
1064 \code{kill(getpid(), sig)}. Siccome \func{raise}, che è definita nello
1065 standard ISO C, non esiste in alcune vecchie versioni di Unix, in generale
1066 l'uso di \func{kill} finisce per essere più portabile.
1068 Una seconda funzione che può essere definita in termini di \func{kill} è
1069 \funcd{killpg}, che è sostanzialmente equivalente a
1070 \code{kill(-pidgrp, signal)}; il suo prototipo è:
1071 \begin{prototype}{signal.h}{int killpg(pid\_t pidgrp, int signal)}
1073 Invia il segnale \param{signal} al \itindex{process~group} \textit{process
1074 group} \param{pidgrp}.
1076 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
1077 errore, gli errori sono gli stessi di \func{kill}.}
1079 \noindent e permette di inviare un segnale a tutto un \itindex{process~group}
1080 \textit{process group} (vedi sez.~\ref{sec:sess_proc_group}).
1085 \begin{tabular}[c]{|r|l|}
1087 \textbf{Valore} & \textbf{Significato} \\
1090 $>0$ & Il segnale è mandato al processo con il \ids{PID} indicato.\\
1091 0 & Il segnale è mandato ad ogni processo del \itindex{process~group}
1092 \textit{process group} del chiamante.\\
1093 $-1$ & Il segnale è mandato ad ogni processo (eccetto \cmd{init}).\\
1094 $<-1$ & Il segnale è mandato ad ogni processo del \textit{process group}
1095 \itindex{process~group} $|\code{pid}|$.\\
1098 \caption{Valori dell'argomento \param{pid} per la funzione
1100 \label{tab:sig_kill_values}
1103 Solo l'amministratore può inviare un segnale ad un processo qualunque, in
1104 tutti gli altri casi l'\ids{UID} reale o l'\ids{UID} effettivo del processo
1105 chiamante devono corrispondere all'\ids{UID} reale o all'\ids{UID} salvato
1106 della destinazione. Fa eccezione il caso in cui il segnale inviato sia
1107 \signal{SIGCONT}, nel quale occorre che entrambi i processi appartengano alla
1108 stessa sessione. Inoltre, dato il ruolo fondamentale che riveste nel sistema
1109 (si ricordi quanto visto in sez.~\ref{sec:sig_termination}), non è possibile
1110 inviare al processo 1 (cioè a \cmd{init}) segnali per i quali esso non abbia
1111 un gestore installato.
1113 Infine, seguendo le specifiche POSIX 1003.1-2001, l'uso della chiamata
1114 \code{kill(-1, sig)} comporta che il segnale sia inviato (con la solita
1115 eccezione di \cmd{init}) a tutti i processi per i quali i permessi lo
1116 consentano. Lo standard permette comunque alle varie implementazioni di
1117 escludere alcuni processi specifici: nel caso in questione Linux non invia il
1118 segnale al processo che ha effettuato la chiamata.
1121 \subsection{Le funzioni \func{alarm}, \func{abort} ed i \textit{timer}}
1122 \label{sec:sig_alarm_abort}
1124 Un caso particolare di segnali generati a richiesta è quello che riguarda i
1125 vari segnali di temporizzazione e \signal{SIGABRT}, per ciascuno di questi
1126 segnali sono previste funzioni specifiche che ne effettuino l'invio. La più
1127 comune delle funzioni usate per la temporizzazione è \funcd{alarm} il cui
1129 \begin{prototype}{unistd.h}{unsigned int alarm(unsigned int seconds)}
1130 Predispone l'invio di \signal{SIGALRM} dopo \param{seconds} secondi.
1132 \bodydesc{La funzione restituisce il numero di secondi rimanenti ad un
1133 precedente allarme, o zero se non c'erano allarmi pendenti.}
1136 La funzione fornisce un meccanismo che consente ad un processo di predisporre
1137 un'interruzione nel futuro, (ad esempio per effettuare una qualche operazione
1138 dopo un certo periodo di tempo), programmando l'emissione di un segnale (nel
1139 caso in questione \signal{SIGALRM}) dopo il numero di secondi specificato da
1142 Se si specifica per \param{seconds} un valore nullo non verrà inviato nessun
1143 segnale; siccome alla chiamata viene cancellato ogni precedente allarme,
1144 questo può essere usato per cancellare una programmazione precedente.
1146 La funzione inoltre ritorna il numero di secondi rimanenti all'invio
1147 dell'allarme programmato in precedenza. In questo modo è possibile controllare
1148 se non si è cancellato un precedente allarme e predisporre eventuali misure
1149 che permettano di gestire il caso in cui servono più interruzioni.
1151 In sez.~\ref{sec:sys_unix_time} abbiamo visto che ad ogni processo sono
1152 associati tre tempi diversi: il \textit{clock time}, l'\textit{user time} ed
1153 il \textit{system time}. Per poterli calcolare il kernel mantiene per ciascun
1154 processo tre diversi timer:
1156 \item un \textit{real-time timer} che calcola il tempo reale trascorso (che
1157 corrisponde al \textit{clock time}). La scadenza di questo timer provoca
1158 l'emissione di \signal{SIGALRM};
1159 \item un \textit{virtual timer} che calcola il tempo di processore usato dal
1160 processo in user space (che corrisponde all'\textit{user time}). La scadenza
1161 di questo timer provoca l'emissione di \signal{SIGVTALRM};
1162 \item un \textit{profiling timer} che calcola la somma dei tempi di processore
1163 utilizzati direttamente dal processo in user space, e dal kernel nelle
1164 system call ad esso relative (che corrisponde a quello che in
1165 sez.~\ref{sec:sys_unix_time} abbiamo chiamato \textit{CPU time}). La scadenza
1166 di questo timer provoca l'emissione di \signal{SIGPROF}.
1169 Il timer usato da \func{alarm} è il \textit{clock time}, e corrisponde cioè al
1170 tempo reale. La funzione come abbiamo visto è molto semplice, ma proprio per
1171 questo presenta numerosi limiti: non consente di usare gli altri timer, non
1172 può specificare intervalli di tempo con precisione maggiore del secondo e
1173 genera il segnale una sola volta.
1175 Per ovviare a questi limiti Linux deriva da BSD la funzione \funcd{setitimer}
1176 che permette di usare un timer qualunque e l'invio di segnali periodici, al
1177 costo però di una maggiore complessità d'uso e di una minore portabilità. Il
1179 \begin{prototype}{sys/time.h}{int setitimer(int which, const struct
1180 itimerval *value, struct itimerval *ovalue)}
1182 Predispone l'invio di un segnale di allarme alla scadenza dell'intervallo
1183 \param{value} sul timer specificato da \param{which}.
1185 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
1186 errore, nel qual caso \var{errno} assumerà uno dei valori \errval{EINVAL} o
1190 Il valore di \param{which} permette di specificare quale dei tre timer
1191 illustrati in precedenza usare; i possibili valori sono riportati in
1192 tab.~\ref{tab:sig_setitimer_values}.
1196 \begin{tabular}[c]{|l|l|}
1198 \textbf{Valore} & \textbf{Timer} \\
1201 \const{ITIMER\_REAL} & \textit{real-time timer}\\
1202 \const{ITIMER\_VIRTUAL} & \textit{virtual timer}\\
1203 \const{ITIMER\_PROF} & \textit{profiling timer}\\
1206 \caption{Valori dell'argomento \param{which} per la funzione
1208 \label{tab:sig_setitimer_values}
1211 Il valore della struttura specificata \param{value} viene usato per impostare
1212 il timer, se il puntatore \param{ovalue} non è nullo il precedente valore
1213 viene salvato qui. I valori dei timer devono essere indicati attraverso una
1214 struttura \struct{itimerval}, definita in fig.~\ref{fig:file_stat_struct}.
1216 La struttura è composta da due membri, il primo, \var{it\_interval} definisce
1217 il periodo del timer; il secondo, \var{it\_value} il tempo mancante alla
1218 scadenza. Entrambi esprimono i tempi tramite una struttura \struct{timeval} che
1219 permette una precisione fino al microsecondo.
1221 Ciascun timer decrementa il valore di \var{it\_value} fino a zero, poi invia
1222 il segnale e reimposta \var{it\_value} al valore di \var{it\_interval}, in
1223 questo modo il ciclo verrà ripetuto; se invece il valore di \var{it\_interval}
1224 è nullo il timer si ferma.
1226 \begin{figure}[!htb]
1227 \footnotesize \centering
1228 \begin{minipage}[c]{\textwidth}
1229 \includestruct{listati/itimerval.h}
1232 \caption{La struttura \structd{itimerval}, che definisce i valori dei timer
1234 \label{fig:sig_itimerval}
1237 L'uso di \func{setitimer} consente dunque un controllo completo di tutte le
1238 caratteristiche dei timer, ed in effetti la stessa \func{alarm}, benché
1239 definita direttamente nello standard POSIX.1, può a sua volta essere espressa
1240 in termini di \func{setitimer}, come evidenziato dal manuale delle \acr{glibc}
1241 \cite{GlibcMan} che ne riporta la definizione mostrata in
1242 fig.~\ref{fig:sig_alarm_def}.\footnote{questo comporta anche che non è il caso
1243 di mescolare chiamate ad \func{abort} e a \func{setitimer}.}
1245 \begin{figure}[!htb]
1246 \footnotesize \centering
1247 \begin{minipage}[c]{\textwidth}
1248 \includestruct{listati/alarm_def.c}
1251 \caption{Definizione di \func{alarm} in termini di \func{setitimer}.}
1252 \label{fig:sig_alarm_def}
1255 Si deve comunque tenere presente che fino al kernel 2.6.16 la precisione di
1256 queste funzioni era limitata dalla frequenza del timer di sistema,\footnote{il
1257 valore della costante \texttt{HZ}, di cui abbiamo già parlato in
1258 sez.~\ref{sec:proc_hierarchy}.} in quanto le temporizzazioni erano calcolate
1259 in numero di interruzioni del timer (i cosiddetti \itindex{jiffies}
1260 ``\textit{jiffies}''), ed era assicurato soltanto che il segnale non sarebbe
1261 stato mai generato prima della scadenza programmata (l'arrotondamento cioè era
1262 effettuato per eccesso).\footnote{questo in realtà non è del tutto vero a
1263 causa di un bug, presente fino al kernel 2.6.12, che in certe circostanze
1264 causava l'emissione del segnale con un arrotondamento per difetto.} L'uso
1265 del contatore dei \itindex{jiffies} \textit{jiffies}, un intero a 32 bit,
1266 comportava inoltre l'impossibilità di specificare tempi molto
1267 lunghi.\footnote{superiori al valore della costante
1268 \const{MAX\_SEC\_IN\_JIFFIES}, pari, nel caso di default di un valore di
1269 \const{HZ} di 250, a circa 99 giorni e mezzo.} Con il cambiamento della
1270 rappresentazione effettuato nel kernel 2.6.16 questo problema è scomparso e
1271 con l'introduzione dei timer ad alta risoluzione (vedi
1272 sez.~\ref{sec:sig_timer_adv}) nel kernel 2.6.21 la precisione è diventata
1273 quella fornita dall'hardware disponibile.
1275 Una seconda causa di potenziali ritardi è che il segnale viene generato alla
1276 scadenza del timer, ma poi deve essere consegnato al processo; se quest'ultimo
1277 è attivo (questo è sempre vero per \const{ITIMER\_VIRT}) la consegna è
1278 immediata, altrimenti può esserci un ulteriore ritardo che può variare a
1279 seconda del carico del sistema.
1281 Questo ha una conseguenza che può indurre ad errori molto subdoli, si tenga
1282 conto poi che in caso di sistema molto carico, si può avere il caso patologico
1283 in cui un timer scade prima che il segnale di una precedente scadenza sia
1284 stato consegnato; in questo caso, per il comportamento dei segnali descritto
1285 in sez.~\ref{sec:sig_sigchld}, un solo segnale sarà consegnato. Per questo
1286 oggi l'uso di questa funzione è deprecato a favore dei \textit{POSIX timer}
1287 che tratteremo in sez.~\ref{sec:sig_timer_adv}.
1289 Dato che sia \func{alarm} che \func{setitimer} non consentono di leggere il
1290 valore corrente di un timer senza modificarlo, è possibile usare la funzione
1291 \funcd{getitimer}, il cui prototipo è:
1292 \begin{prototype}{sys/time.h}{int getitimer(int which, struct
1295 Legge in \param{value} il valore del timer specificato da \param{which}.
1297 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
1298 errore e restituisce gli stessi errori di \func{getitimer}.}
1300 \noindent i cui argomenti hanno lo stesso significato e formato di quelli di
1304 L'ultima funzione che permette l'invio diretto di un segnale è \funcd{abort},
1305 che, come accennato in sez.~\ref{sec:proc_termination}, permette di abortire
1306 l'esecuzione di un programma tramite l'invio di \signal{SIGABRT}. Il suo
1308 \begin{prototype}{stdlib.h}{void abort(void)}
1310 Abortisce il processo corrente.
1312 \bodydesc{La funzione non ritorna, il processo è terminato inviando il
1313 segnale di \signal{SIGABRT}.}
1316 La differenza fra questa funzione e l'uso di \func{raise} è che anche se il
1317 segnale è bloccato o ignorato, la funzione ha effetto lo stesso. Il segnale
1318 può però essere intercettato per effettuare eventuali operazioni di chiusura
1319 prima della terminazione del processo.
1321 Lo standard ANSI C richiede inoltre che anche se il gestore ritorna, la
1322 funzione non ritorni comunque. Lo standard POSIX.1 va oltre e richiede che se
1323 il processo non viene terminato direttamente dal gestore sia la stessa
1324 \func{abort} a farlo al ritorno dello stesso. Inoltre, sempre seguendo lo
1325 standard POSIX, prima della terminazione tutti i file aperti e gli stream
1326 saranno chiusi ed i buffer scaricati su disco. Non verranno invece eseguite le
1327 eventuali funzioni registrate con \func{atexit} e \func{on\_exit}.
1330 \subsection{Le funzioni di pausa e attesa}
1331 \label{sec:sig_pause_sleep}
1333 Sono parecchie le occasioni in cui si può avere necessità di sospendere
1334 temporaneamente l'esecuzione di un processo. Nei sistemi più elementari in
1335 genere questo veniva fatto con un opportuno loop di attesa, ma in un sistema
1336 multitasking un loop di attesa è solo un inutile spreco di CPU, per questo ci
1337 sono apposite funzioni che permettono di mettere un processo in stato di
1338 attesa.\footnote{si tratta in sostanza di funzioni che permettono di portare
1339 esplicitamente il processo in stato di \textit{sleep}, vedi
1340 sez.~\ref{sec:proc_sched}.}
1342 Il metodo tradizionale per fare attendere ad un processo fino all'arrivo di un
1343 segnale è quello di usare la funzione \funcd{pause}, il cui prototipo è:
1344 \begin{prototype}{unistd.h}{int pause(void)}
1346 Pone il processo in stato di sleep fino al ritorno di un gestore.
1348 \bodydesc{La funzione ritorna solo dopo che un segnale è stato ricevuto ed
1349 il relativo gestore è ritornato, nel qual caso restituisce $-1$ e
1350 \var{errno} assumerà il valore \errval{EINTR}.}
1353 La funzione segnala sempre una condizione di errore (il successo sarebbe
1354 quello di aspettare indefinitamente). In genere si usa questa funzione quando
1355 si vuole mettere un processo in attesa di un qualche evento specifico che non
1356 è sotto il suo diretto controllo (ad esempio la si può usare per interrompere
1357 l'esecuzione del processo fino all'arrivo di un segnale inviato da un altro
1360 Quando invece si vuole fare attendere un processo per un intervallo di tempo
1361 già noto nello standard POSIX.1 viene definita la funzione \funcd{sleep}, il
1363 \begin{prototype}{unistd.h}{unsigned int sleep(unsigned int seconds)}
1365 Pone il processo in stato di sleep per \param{seconds} secondi.
1367 \bodydesc{La funzione restituisce zero se l'attesa viene completata, o il
1368 numero di secondi restanti se viene interrotta da un segnale.}
1371 La funzione attende per il tempo specificato, a meno di non essere interrotta
1372 da un segnale. In questo caso non è una buona idea ripetere la chiamata per il
1373 tempo rimanente, in quanto la riattivazione del processo può avvenire in un
1374 qualunque momento, ma il valore restituito sarà sempre arrotondato al secondo,
1375 con la conseguenza che, se la successione dei segnali è particolarmente
1376 sfortunata e le differenze si accumulano, si potranno avere ritardi anche di
1377 parecchi secondi. In genere la scelta più sicura è quella di stabilire un
1378 termine per l'attesa, e ricalcolare tutte le volte il numero di secondi da
1381 In alcune implementazioni inoltre l'uso di \func{sleep} può avere conflitti
1382 con quello di \signal{SIGALRM}, dato che la funzione può essere realizzata con
1383 l'uso di \func{pause} e \func{alarm} (in maniera analoga all'esempio che
1384 vedremo in sez.~\ref{sec:sig_example}). In tal caso mescolare chiamata di
1385 \func{alarm} e \func{sleep} o modificare l'azione di \signal{SIGALRM}, può
1386 causare risultati indefiniti. Nel caso delle \acr{glibc} è stata usata una
1387 implementazione completamente indipendente e questi problemi non ci sono.
1389 La granularità di \func{sleep} permette di specificare attese soltanto in
1390 secondi, per questo sia sotto BSD4.3 che in SUSv2 è stata definita la funzione
1391 \funcd{usleep} (dove la \texttt{u} è intesa come sostituzione di $\mu$); i due
1392 standard hanno delle definizioni diverse, ma le \acr{glibc}
1393 seguono\footnote{secondo la pagina di manuale almeno dalla versione 2.2.2.}
1394 seguono quella di SUSv2 che prevede il seguente prototipo:
1395 \begin{prototype}{unistd.h}{int usleep(unsigned long usec)}
1397 Pone il processo in stato di sleep per \param{usec} microsecondi.
1399 \bodydesc{La funzione restituisce zero se l'attesa viene completata, o $-1$
1400 in caso di errore, nel qual caso \var{errno} assumerà il valore
1405 Anche questa funzione, a seconda delle implementazioni, può presentare
1406 problemi nell'interazione con \func{alarm} e \signal{SIGALRM}. È pertanto
1407 deprecata in favore della funzione \funcd{nanosleep}, definita dallo standard
1408 POSIX1.b, il cui prototipo è:
1409 \begin{prototype}{unistd.h}{int nanosleep(const struct timespec *req, struct
1412 Pone il processo in stato di sleep per il tempo specificato da \param{req}.
1413 In caso di interruzione restituisce il tempo restante in \param{rem}.
1415 \bodydesc{La funzione restituisce zero se l'attesa viene completata, o $-1$
1416 in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
1418 \item[\errcode{EINVAL}] si è specificato un numero di secondi negativo o un
1419 numero di nanosecondi maggiore di 999.999.999.
1420 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
1424 Lo standard richiede che la funzione sia implementata in maniera del tutto
1425 indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto
1426 utilizzando direttamente il timer del kernel.} e sia utilizzabile senza
1427 interferenze con l'uso di \signal{SIGALRM}. La funzione prende come argomenti
1428 delle strutture di tipo \struct{timespec}, la cui definizione è riportata in
1429 fig.~\ref{fig:sys_timespec_struct}, che permette di specificare un tempo con
1430 una precisione fino al nanosecondo.
1432 La funzione risolve anche il problema di proseguire l'attesa dopo
1433 l'interruzione dovuta ad un segnale; infatti in tal caso in \param{rem} viene
1434 restituito il tempo rimanente rispetto a quanto richiesto
1435 inizialmente,\footnote{con l'eccezione, valida solo nei kernel della serie
1436 2.4, in cui, per i processi riavviati dopo essere stati fermati da un
1437 segnale, il tempo passato in stato \texttt{T} non viene considerato nel
1438 calcolo della rimanenza.} e basta richiamare la funzione per completare
1439 l'attesa.\footnote{anche qui però occorre tenere presente che i tempi sono
1440 arrotondati, per cui la precisione, per quanto migliore di quella ottenibile
1441 con \func{sleep}, è relativa e in caso di molte interruzioni si può avere
1442 una deriva, per questo esiste la funzione \func{clock\_nanosleep} (vedi
1443 sez.~\ref{sec:sig_timer_adv}) che permette di specificare un tempo assoluto
1444 anziché un tempo relativo.}
1446 Chiaramente, anche se il tempo può essere specificato con risoluzioni fino al
1447 nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
1448 temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
1449 specificato, ma prima che il processo possa tornare ad essere eseguito
1450 occorrerà almeno attendere la successiva interruzione del timer di sistema,
1451 cioè un tempo che a seconda dei casi può arrivare fino a 1/\const{HZ}, (sempre
1452 che il sistema sia scarico ed il processa venga immediatamente rimesso in
1453 esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
1454 arrotondato al multiplo successivo di 1/\const{HZ}.
1456 Con i kernel della serie 2.4 in realtà era possibile ottenere anche pause più
1457 precise del centesimo di secondo usando politiche di \itindex{scheduler}
1458 scheduling \textit{real-time} come \const{SCHED\_FIFO} o \const{SCHED\_RR}; in
1459 tal caso infatti il calcolo sul numero di interruzioni del timer veniva
1460 evitato utilizzando direttamente un ciclo di attesa con cui si raggiungevano
1461 pause fino ai 2~ms con precisioni del $\mu$s. Questa estensione è stata
1462 rimossa con i kernel della serie 2.6, che consentono una risoluzione più alta
1463 del timer di sistema; inoltre a partire dal kernel 2.6.21, \func{nanosleep}
1464 può avvalersi del supporto dei timer ad alta risoluzione, ottenendo la massima
1465 precisione disponibile sull'hardware della propria macchina.
1468 \subsection{Un esempio elementare}
1469 \label{sec:sig_sigchld}
1471 Un semplice esempio per illustrare il funzionamento di un gestore di segnale è
1472 quello della gestione di \signal{SIGCHLD}. Abbiamo visto in
1473 sez.~\ref{sec:proc_termination} che una delle azioni eseguite dal kernel alla
1474 conclusione di un processo è quella di inviare questo segnale al
1475 padre.\footnote{in realtà in SVr4 eredita la semantica di System V, in cui il
1476 segnale si chiama \signal{SIGCLD} e viene trattato in maniera speciale; in
1477 System V infatti se si imposta esplicitamente l'azione a \const{SIG\_IGN} il
1478 segnale non viene generato ed il sistema non genera \itindex{zombie}
1479 \textit{zombie} (lo stato di terminazione viene scartato senza dover
1480 chiamare una \func{wait}). L'azione predefinita è sempre quella di ignorare
1481 il segnale, ma non attiva questo comportamento. Linux, come BSD e POSIX, non
1482 supporta questa semantica ed usa il nome di \signal{SIGCLD} come sinonimo di
1483 \signal{SIGCHLD}.} In generale dunque, quando non interessa elaborare lo
1484 stato di uscita di un processo, si può completare la gestione della
1485 terminazione installando un gestore per \signal{SIGCHLD} il cui unico compito
1486 sia quello di chiamare \func{waitpid} per completare la procedura di
1487 terminazione in modo da evitare la formazione di \itindex{zombie}
1490 In fig.~\ref{fig:sig_sigchld_handl} è mostrato il codice contenente una
1491 implementazione generica di una funzione di gestione per \signal{SIGCHLD},
1492 (che si trova nei sorgenti allegati nel file \file{SigHand.c}); se ripetiamo i
1493 test di sez.~\ref{sec:proc_termination}, invocando \cmd{forktest} con
1494 l'opzione \cmd{-s} (che si limita ad effettuare l'installazione di questa
1495 funzione come gestore di \signal{SIGCHLD}) potremo verificare che non si ha
1496 più la creazione di \itindex{zombie} \textit{zombie}.
1498 \begin{figure}[!htbp]
1499 \footnotesize \centering
1500 \begin{minipage}[c]{\codesamplewidth}
1501 \includecodesample{listati/hand_sigchild.c}
1504 \caption{Codice di una funzione generica di gestione per il segnale
1506 \label{fig:sig_sigchld_handl}
1509 Il codice del gestore è di lettura immediata; come buona norma di
1510 programmazione (si ricordi quanto accennato sez.~\ref{sec:sys_errno}) si
1511 comincia (\texttt{\small 6--7}) con il salvare lo stato corrente di
1512 \var{errno}, in modo da poterlo ripristinare prima del ritorno del gestore
1513 (\texttt{\small 16--17}). In questo modo si preserva il valore della variabile
1514 visto dal corso di esecuzione principale del processo, che altrimenti sarebbe
1515 sovrascritto dal valore restituito nella successiva chiamata di \func{waitpid}.
1517 Il compito principale del gestore è quello di ricevere lo stato di
1518 terminazione del processo, cosa che viene eseguita nel ciclo in
1519 (\texttt{\small 9--15}). Il ciclo è necessario a causa di una caratteristica
1520 fondamentale della gestione dei segnali: abbiamo già accennato come fra la
1521 generazione di un segnale e l'esecuzione del gestore possa passare un certo
1522 lasso di tempo e niente ci assicura che il gestore venga eseguito prima della
1523 generazione di ulteriori segnali dello stesso tipo. In questo caso normalmente
1524 i segnali successivi vengono ``\textsl{fusi}'' col primo ed al processo ne
1525 viene recapitato soltanto uno.
1527 Questo può essere un caso comune proprio con \signal{SIGCHLD}, qualora capiti
1528 che molti processi figli terminino in rapida successione. Esso inoltre si
1529 presenta tutte le volte che un segnale viene bloccato: per quanti siano i
1530 segnali emessi durante il periodo di blocco, una volta che quest'ultimo sarà
1531 rimosso verrà recapitato un solo segnale.
1533 Allora, nel caso della terminazione dei processi figli, se si chiamasse
1534 \func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un
1535 solo processo, anche se i processi terminati sono più di uno, e gli altri
1536 resterebbero in stato di \itindex{zombie} \textit{zombie} per un tempo
1539 Per questo occorre ripetere la chiamata di \func{waitpid} fino a che essa non
1540 ritorni un valore nullo, segno che non resta nessun processo di cui si debba
1541 ancora ricevere lo stato di terminazione (si veda sez.~\ref{sec:proc_wait} per
1542 la sintassi della funzione). Si noti anche come la funzione venga invocata con
1543 il parametro \const{WNOHANG} che permette di evitare il suo blocco quando
1544 tutti gli stati di terminazione sono stati ricevuti.
1548 \section{La gestione avanzata dei segnali}
1549 \label{sec:sig_adv_control}
1551 Le funzioni esaminate finora fanno riferimento alle modalità più elementari
1552 della gestione dei segnali; non si sono pertanto ancora prese in
1553 considerazione le tematiche più complesse, collegate alle varie
1554 \itindex{race~condition} \textit{race condition} che i segnali possono
1555 generare e alla natura asincrona degli stessi.
1557 Affronteremo queste problematiche in questa sezione, partendo da un esempio
1558 che le evidenzi, per poi prendere in esame le varie funzioni che permettono di
1559 risolvere i problemi più complessi connessi alla programmazione con i segnali,
1560 fino a trattare le caratteristiche generali della gestione dei medesimi nella
1561 casistica ordinaria.
1564 \subsection{Alcune problematiche aperte}
1565 \label{sec:sig_example}
1567 Come accennato in sez.~\ref{sec:sig_pause_sleep} è possibile implementare
1568 \func{sleep} a partire dall'uso di \func{pause} e \func{alarm}. A prima vista
1569 questo può sembrare di implementazione immediata; ad esempio una semplice
1570 versione di \func{sleep} potrebbe essere quella illustrata in
1571 fig.~\ref{fig:sig_sleep_wrong}.
1573 \begin{figure}[!htbp]
1574 \footnotesize \centering
1575 \begin{minipage}[c]{\codesamplewidth}
1576 \includecodesample{listati/sleep_danger.c}
1579 \caption{Una implementazione pericolosa di \func{sleep}.}
1580 \label{fig:sig_sleep_wrong}
1583 Dato che è nostra intenzione utilizzare \signal{SIGALRM} il primo passo della
1584 nostra implementazione sarà quello di installare il relativo gestore salvando
1585 il precedente (\texttt{\small 14-17}). Si effettuerà poi una chiamata ad
1586 \func{alarm} per specificare il tempo d'attesa per l'invio del segnale a cui
1587 segue la chiamata a \func{pause} per fermare il programma (\texttt{\small
1588 18-20}) fino alla sua ricezione. Al ritorno di \func{pause}, causato dal
1589 ritorno del gestore (\texttt{\small 1-9}), si ripristina il gestore originario
1590 (\texttt{\small 21-22}) restituendo l'eventuale tempo rimanente
1591 (\texttt{\small 23-24}) che potrà essere diverso da zero qualora
1592 l'interruzione di \func{pause} venisse causata da un altro segnale.
1594 Questo codice però, a parte il non gestire il caso in cui si è avuta una
1595 precedente chiamata a \func{alarm} (che si è tralasciato per brevità),
1596 presenta una pericolosa \itindex{race~condition} \textit{race condition}.
1597 Infatti, se il processo viene interrotto fra la chiamata di \func{alarm} e
1598 \func{pause}, può capitare (ad esempio se il sistema è molto carico) che il
1599 tempo di attesa scada prima dell'esecuzione di quest'ultima, cosicché essa
1600 sarebbe eseguita dopo l'arrivo di \signal{SIGALRM}. In questo caso ci si
1601 troverebbe di fronte ad un \itindex{deadlock} deadlock, in quanto \func{pause}
1602 non verrebbe mai più interrotta (se non in caso di un altro segnale).
1604 Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
1605 SVr2) usando la funzione \func{longjmp} (vedi sez.~\ref{sec:proc_longjmp}) per
1606 uscire dal gestore; in questo modo, con una condizione sullo stato di
1607 uscita di quest'ultima, si può evitare la chiamata a \func{pause}, usando un
1608 codice del tipo di quello riportato in fig.~\ref{fig:sig_sleep_incomplete}.
1610 \begin{figure}[!htbp]
1611 \footnotesize \centering
1612 \begin{minipage}[c]{\codesamplewidth}
1613 \includecodesample{listati/sleep_defect.c}
1616 \caption{Una implementazione ancora malfunzionante di \func{sleep}.}
1617 \label{fig:sig_sleep_incomplete}
1620 In questo caso il gestore (\texttt{\small 18-27}) non ritorna come in
1621 fig.~\ref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 25}) per
1622 rientrare nel corpo principale del programma; dato che in questo caso il
1623 valore di uscita di \func{setjmp} è 1, grazie alla condizione in
1624 (\texttt{\small 9-12}) si evita comunque che \func{pause} sia chiamata a
1627 Ma anche questa implementazione comporta dei problemi; in questo caso infatti
1628 non viene gestita correttamente l'interazione con gli altri segnali; se
1629 infatti il segnale di allarme interrompe un altro gestore, l'esecuzione non
1630 riprenderà nel gestore in questione, ma nel ciclo principale, interrompendone
1631 inopportunamente l'esecuzione. Lo stesso tipo di problemi si presenterebbero
1632 se si volesse usare \func{alarm} per stabilire un timeout su una qualunque
1633 system call bloccante.
1635 Un secondo esempio è quello in cui si usa il segnale per notificare una
1636 qualche forma di evento; in genere quello che si fa in questo caso è impostare
1637 nel gestore un opportuno flag da controllare nel corpo principale del
1638 programma (con un codice del tipo di quello riportato in
1639 fig.~\ref{fig:sig_event_wrong}). La logica è quella di far impostare al
1640 gestore (\texttt{\small 14-19}) una \index{variabili!globali} variabile
1641 globale preventivamente inizializzata nel programma principale, il quale potrà
1642 determinare, osservandone il contenuto, l'occorrenza o meno del segnale, e
1643 prendere le relative azioni conseguenti (\texttt{\small 6-11}).
1645 \begin{figure}[!htbp]
1646 \footnotesize\centering
1647 \begin{minipage}[c]{\codesamplewidth}
1648 \includecodesample{listati/sig_alarm.c}
1651 \caption{Un esempio non funzionante del codice per il controllo di un
1652 evento generato da un segnale.}
1653 \label{fig:sig_event_wrong}
1656 Questo è il tipico esempio di caso, già citato in
1657 sez.~\ref{sec:proc_race_cond}, in cui si genera una \itindex{race~condition}
1658 \textit{race condition}; infatti, in una situazione in cui un segnale è già
1659 arrivato (e \var{flag} è già ad 1) se un altro segnale arriva immediatamente
1660 dopo l'esecuzione del controllo (\texttt{\small 6}) ma prima della
1661 cancellazione del flag (\texttt{\small 7}), la sua occorrenza sarà perduta.
1663 Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono
1664 delle funzioni più sofisticate di quelle finora illustrate, queste hanno la
1665 loro origine nella semplice interfaccia dei primi sistemi Unix, ma con esse
1666 non è possibile gestire in maniera adeguata di tutti i possibili aspetti con
1667 cui un processo deve reagire alla ricezione di un segnale.
1671 \subsection{Gli \textsl{insiemi di segnali} o \textit{signal set}}
1672 \label{sec:sig_sigset}
1674 \itindbeg{signal~set}
1676 Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali
1677 originarie, nate con la semantica inaffidabile, hanno dei limiti non
1678 superabili; in particolare non è prevista nessuna funzione che permetta di
1679 gestire il blocco dei segnali o di verificare lo stato dei segnali pendenti.
1680 Per questo motivo lo standard POSIX.1, insieme alla nuova semantica dei
1681 segnali ha introdotto una interfaccia di gestione completamente nuova, che
1682 permette di ottenere un controllo molto più dettagliato. In particolare lo
1683 standard ha introdotto un nuovo tipo di dato \type{sigset\_t}, che permette di
1684 rappresentare un \textsl{insieme di segnali} (un \textit{signal set}, come
1685 viene usualmente chiamato), tale tipo di dato viene usato per gestire il
1688 In genere un \textsl{insieme di segnali} è rappresentato da un intero di
1689 dimensione opportuna, di solito pari al numero di bit dell'architettura della
1690 macchina,\footnote{nel caso dei PC questo comporta un massimo di 32 segnali
1691 distinti: dato che in Linux questi sono sufficienti non c'è necessità di
1692 nessuna struttura più complicata.} ciascun bit del quale è associato ad uno
1693 specifico segnale; in questo modo è di solito possibile implementare le
1694 operazioni direttamente con istruzioni elementari del processore. Lo standard
1695 POSIX.1 definisce cinque funzioni per la manipolazione degli insiemi di
1696 segnali: \funcd{sigemptyset}, \funcd{sigfillset}, \funcd{sigaddset},
1697 \funcd{sigdelset} e \funcd{sigismember}, i cui prototipi sono:
1701 \funcdecl{int sigemptyset(sigset\_t *set)} Inizializza un insieme di segnali
1702 vuoto (in cui non c'è nessun segnale).
1704 \funcdecl{int sigfillset(sigset\_t *set)} Inizializza un insieme di segnali
1705 pieno (in cui ci sono tutti i segnali).
1707 \funcdecl{int sigaddset(sigset\_t *set, int signum)} Aggiunge il segnale
1708 \param{signum} all'insieme di segnali \param{set}.
1710 \funcdecl{int sigdelset(sigset\_t *set, int signum)} Toglie il segnale
1711 \param{signum} dall'insieme di segnali \param{set}.
1713 \funcdecl{int sigismember(const sigset\_t *set, int signum)} Controlla se il
1714 segnale \param{signum} è nell'insieme di segnali \param{set}.
1716 \bodydesc{Le prime quattro funzioni ritornano 0 in caso di successo, mentre
1717 \func{sigismember} ritorna 1 se \param{signum} è in \param{set} e 0
1718 altrimenti. In caso di errore tutte ritornano $-1$, con \var{errno}
1719 impostata a \errval{EINVAL} (il solo errore possibile è che \param{signum}
1720 non sia un segnale valido).}
1723 Dato che in generale non si può fare conto sulle caratteristiche di una
1724 implementazione (non è detto che si disponga di un numero di bit sufficienti
1725 per mettere tutti i segnali in un intero, o in \type{sigset\_t} possono essere
1726 immagazzinate ulteriori informazioni) tutte le operazioni devono essere
1727 comunque eseguite attraverso queste funzioni.
1729 In genere si usa un insieme di segnali per specificare quali segnali si vuole
1730 bloccare, o per riottenere dalle varie funzioni di gestione la maschera dei
1731 segnali attivi (vedi sez.~\ref{sec:sig_sigmask}). Essi possono essere definiti
1732 in due diverse maniere, aggiungendo i segnali voluti ad un insieme vuoto
1733 ottenuto con \func{sigemptyset} o togliendo quelli che non servono da un
1734 insieme completo ottenuto con \func{sigfillset}. Infine \func{sigismember}
1735 permette di verificare la presenza di uno specifico segnale in un
1738 \itindend{signal~set}
1741 \subsection{La funzione \func{sigaction}}
1742 \label{sec:sig_sigaction}
1744 Abbiamo già accennato in sez.~\ref{sec:sig_signal} i problemi di compatibilità
1745 relativi all'uso di \func{signal}. Per ovviare a tutto questo lo standard
1746 POSIX.1 ha ridefinito completamente l'interfaccia per la gestione dei segnali,
1747 rendendola molto più flessibile e robusta, anche se leggermente più complessa.
1749 La funzione principale dell'interfaccia POSIX.1 per i segnali è
1750 \funcd{sigaction}. Essa ha sostanzialmente lo stesso uso di \func{signal},
1751 permette cioè di specificare le modalità con cui un segnale può essere gestito
1752 da un processo. Il suo prototipo è:
1753 \begin{prototype}{signal.h}{int sigaction(int signum, const struct sigaction
1754 *act, struct sigaction *oldact)}
1756 Installa una nuova azione per il segnale \param{signum}.
1758 \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
1759 errore, nel qual caso \var{errno} assumerà i valori:
1761 \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido o si è
1762 cercato di installare il gestore per \signal{SIGKILL} o
1764 \item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
1768 La funzione serve ad installare una nuova \textsl{azione} per il segnale
1769 \param{signum}; si parla di \textsl{azione} e non di \textsl{gestore}
1770 come nel caso di \func{signal}, in quanto la funzione consente di specificare
1771 le varie caratteristiche della risposta al segnale, non solo la funzione che
1772 verrà eseguita alla sua occorrenza. Per questo lo standard raccomanda di
1773 usare sempre questa funzione al posto di \func{signal} (che in genere viene
1774 definita tramite essa), in quanto permette un controllo completo su tutti gli
1775 aspetti della gestione di un segnale, sia pure al prezzo di una maggiore
1778 Se il puntatore \param{act} non è nullo, la funzione installa la nuova azione
1779 da esso specificata, se \param{oldact} non è nullo il valore dell'azione
1780 corrente viene restituito indietro. Questo permette (specificando \param{act}
1781 nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
1782 che non consente di ottenere l'azione corrente senza installarne una nuova.
1784 Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
1785 tramite la quale si specificano tutte le caratteristiche dell'azione associata
1786 ad un segnale. Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
1787 definita secondo quanto riportato in fig.~\ref{fig:sig_sigaction}. Il campo
1788 \var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
1791 \begin{figure}[!htb]
1792 \footnotesize \centering
1793 \begin{minipage}[c]{\textwidth}
1794 \includestruct{listati/sigaction.h}
1797 \caption{La struttura \structd{sigaction}.}
1798 \label{fig:sig_sigaction}
1801 Il campo \var{sa\_mask} serve ad indicare l'insieme dei segnali che devono
1802 essere bloccati durante l'esecuzione del gestore, ad essi viene comunque
1803 sempre aggiunto il segnale che ne ha causato la chiamata, a meno che non si
1804 sia specificato con \var{sa\_flag} un comportamento diverso. Quando il
1805 gestore ritorna comunque la maschera dei segnali bloccati (vedi
1806 sez.~\ref{sec:sig_sigmask}) viene ripristinata al valore precedente
1809 L'uso di questo campo permette ad esempio di risolvere il problema residuo
1810 dell'implementazione di \code{sleep} mostrata in
1811 fig.~\ref{fig:sig_sleep_incomplete}. In quel caso infatti se il segnale di
1812 allarme avesse interrotto un altro gestore questo non sarebbe stato eseguito
1813 correttamente; la cosa poteva essere prevenuta installando gli altri gestori
1814 usando \var{sa\_mask} per bloccare \signal{SIGALRM} durante la loro esecuzione.
1815 Il valore di \var{sa\_flag} permette di specificare vari aspetti del
1816 comportamento di \func{sigaction}, e della reazione del processo ai vari
1817 segnali; i valori possibili ed il relativo significato sono riportati in
1818 tab.~\ref{tab:sig_sa_flag}.
1823 \begin{tabular}[c]{|l|p{8cm}|}
1825 \textbf{Valore} & \textbf{Significato} \\
1828 \const{SA\_NOCLDSTOP}& Se il segnale è \signal{SIGCHLD} allora non deve
1829 essere notificato quando il processo figlio viene
1830 fermato da uno dei segnali \signal{SIGSTOP},
1831 \signal{SIGTSTP}, \signal{SIGTTIN} o
1833 \const{SA\_RESETHAND}& Ristabilisce l'azione per il segnale al valore
1834 predefinito una volta che il gestore è stato
1835 lanciato, riproduce cioè il comportamento della
1836 semantica inaffidabile.\\
1837 \const{SA\_ONESHOT} & Nome obsoleto, sinonimo non standard di
1838 \const{SA\_RESETHAND}; da evitare.\\
1839 \const{SA\_ONSTACK} & Stabilisce l'uso di uno \itindex{stack}
1840 \textit{stack} alternativo per l'esecuzione del
1842 sez.~\ref{sec:sig_specific_features}).\\
1843 \const{SA\_RESTART} & Riavvia automaticamente le \textit{slow system
1844 call} quando vengono interrotte dal suddetto
1845 segnale; riproduce cioè il comportamento standard
1846 di BSD.\index{system~call~lente}\\
1847 \const{SA\_NODEFER} & Evita che il segnale corrente sia bloccato durante
1848 l'esecuzione del gestore.\\
1849 \const{SA\_NOMASK} & Nome obsoleto, sinonimo non standard di
1850 \const{SA\_NODEFER}.\\
1851 \const{SA\_SIGINFO} & Deve essere specificato quando si vuole usare un
1852 gestore in forma estesa usando
1853 \var{sa\_sigaction} al posto di
1854 \var{sa\_handler}.\\
1855 \const{SA\_NOCLDWAIT}& Se il segnale è \signal{SIGCHLD} allora i processi
1856 figli non diventano \itindex{zombie}
1857 \textit{zombie} quando terminano.\footnotemark \\
1860 \caption{Valori del campo \var{sa\_flag} della struttura \struct{sigaction}.}
1861 \label{tab:sig_sa_flag}
1864 \footnotetext{questa funzionalità è stata introdotta nel kernel 2.6 e va a
1865 modificare il comportamento di \func{waitpid}.}
1867 Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette
1868 di utilizzare due forme diverse di gestore,\footnote{la possibilità è prevista
1869 dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x
1870 con l'introduzione dei segnali \textit{real-time} (vedi
1871 sez.~\ref{sec:sig_real_time}); in precedenza era possibile ottenere alcune
1872 informazioni addizionali usando \var{sa\_handler} con un secondo parametro
1873 addizionale di tipo \var{sigcontext}, che adesso è deprecato.} da
1874 specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO},
1875 rispettivamente attraverso i campi \var{sa\_sigaction} o
1876 \var{sa\_handler},\footnote{i due campi devono essere usati in maniera
1877 alternativa, in certe implementazioni questi campi vengono addirittura
1878 definiti come \direct{union}.} Quest'ultima è quella classica usata anche con
1879 \func{signal}, mentre la prima permette di usare un gestore più complesso, in
1880 grado di ricevere informazioni più dettagliate dal sistema, attraverso la
1881 struttura \struct{siginfo\_t}, riportata in fig.~\ref{fig:sig_siginfo_t}.
1883 Installando un gestore di tipo \var{sa\_sigaction} diventa allora possibile
1884 accedere alle informazioni restituite attraverso il puntatore a questa
1885 struttura. Tutti i segnali impostano i campi \var{si\_signo}, che riporta il
1886 numero del segnale ricevuto, \var{si\_errno}, che riporta, quando diverso da
1887 zero, il codice dell'errore associato al segnale, e \var{si\_code}, che viene
1888 usato dal kernel per specificare maggiori dettagli riguardo l'evento che ha
1889 causato l'emissione del segnale.
1891 \begin{figure}[!htb]
1892 \footnotesize \centering
1893 \begin{minipage}[c]{\textwidth}
1894 \includestruct{listati/siginfo_t.h}
1897 \caption{La struttura \structd{siginfo\_t}.}
1898 \label{fig:sig_siginfo_t}
1901 In generale \var{si\_code} contiene, per i segnali generici, per quelli
1902 \textit{real-time} e per tutti quelli inviati tramite da un processo con
1903 \func{kill} o affini, le informazioni circa l'origine del segnale stesso, ad
1904 esempio se generato dal kernel, da un timer, da \func{kill}, ecc. Il valore
1905 viene sempre espresso come una costante,\footnote{le definizioni di tutti i
1906 valori possibili si trovano in \file{bits/siginfo.h}.} ed i valori possibili
1907 in questo caso sono riportati in tab.~\ref{tab:sig_si_code_generic}.
1909 Nel caso di alcuni segnali però il valore di \var{si\_code} viene usato per
1910 fornire una informazione specifica relativa alle motivazioni della ricezione
1911 dello stesso; ad esempio i vari segnali di errore (\signal{SIGILL},
1912 \signal{SIGFPE}, \signal{SIGSEGV} e \signal{SIGBUS}) lo usano per fornire
1913 maggiori dettagli riguardo l'errore, come il tipo di errore aritmetico, di
1914 istruzione illecita o di violazione di memoria; mentre alcuni segnali di
1915 controllo (\signal{SIGCHLD}, \signal{SIGTRAP} e \signal{SIGPOLL}) forniscono
1916 altre informazioni specifiche.
1921 \begin{tabular}[c]{|l|p{8cm}|}
1923 \textbf{Valore} & \textbf{Significato} \\
1926 \const{SI\_USER} & generato da \func{kill} o \func{raise}.\\
1927 \const{SI\_KERNEL} & inviato dal kernel.\\
1928 \const{SI\_QUEUE} & inviato con \func{sigqueue} (vedi
1929 sez.~\ref{sec:sig_real_time}).\\
1930 \const{SI\_TIMER} & scadenza di un POSIX timer
1931 (vedi sez.~\ref{sec:sig_timer_adv}).\\
1932 \const{SI\_MESGQ} & inviato al cambiamento di stato di una coda di
1933 messaggi POSIX (vedi
1934 sez.~\ref{sec:ipc_posix_mq}).\footnotemark\\
1935 \const{SI\_ASYNCIO}& una operazione di I/O asincrono (vedi
1936 sez.~\ref{sec:file_asyncronous_io}) è stata
1938 \const{SI\_SIGIO} & segnale di \signal{SIGIO} da una coda (vedi
1939 sez.~\ref{sec:file_asyncronous_operation}).\\
1940 \const{SI\_TKILL} & inviato da \func{tkill} o \func{tgkill} (vedi
1941 sez.~\ref{cha:threads_xxx}).\footnotemark\\
1944 \caption{Valori del campo \var{si\_code} della struttura \struct{sigaction}
1945 per i segnali generici.}
1946 \label{tab:sig_si_code_generic}
1949 \footnotetext[24]{introdotto con il kernel 2.6.6.}
1950 \footnotetext{introdotto con il kernel 2.4.19.}
1952 In questo caso il valore del campo \var{si\_code} deve essere verificato nei
1953 confronti delle diverse costanti previste per ciascuno di detti
1954 segnali;\footnote{dato che si tratta di una costante, e non di una maschera
1955 binaria, i valori numerici vengono riutilizzati e ciascuno di essi avrà un
1956 significato diverso a seconda del segnale a cui è associato.} l'elenco
1957 dettagliato dei nomi di queste costanti è riportato nelle diverse sezioni di
1958 tab.~\ref{tab:sig_si_code_special} che sono state ordinate nella sequenza in
1959 cui si sono appena citati i rispettivi segnali.\footnote{il prefisso del nome
1960 indica comunque in maniera diretta il segnale a cui le costanti fanno
1966 \begin{tabular}[c]{|l|p{8cm}|}
1968 \textbf{Valore} & \textbf{Significato} \\
1971 \const{ILL\_ILLOPC} & codice di operazione illegale.\\
1972 \const{ILL\_ILLOPN} & operando illegale.\\
1973 \const{ILL\_ILLADR} & modo di indirizzamento illegale.\\
1974 \const{ILL\_ILLTRP} & trappola di processore illegale.\\
1975 \const{ILL\_PRVOPC} & codice di operazione privilegiato.\\
1976 \const{ILL\_PRVREG} & registro privilegiato.\\
1977 \const{ILL\_COPROC} & errore del coprocessore.\\
1978 \const{ILL\_BADSTK} & errore nello stack interno.\\
1980 \const{FPE\_INTDIV} & divisione per zero intera.\\
1981 \const{FPE\_INTOVF} & overflow intero.\\
1982 \const{FPE\_FLTDIV} & divisione per zero in virgola mobile.\\
1983 \const{FPE\_FLTOVF} & overflow in virgola mobile.\\
1984 \const{FPE\_FLTUND} & underflow in virgola mobile.\\
1985 \const{FPE\_FLTRES} & risultato in virgola mobile non esatto.\\
1986 \const{FPE\_FLTINV} & operazione in virgola mobile non valida.\\
1987 \const{FPE\_FLTSUB} & mantissa? fuori intervallo.\\
1989 \const{SEGV\_MAPERR} & indirizzo non mappato.\\
1990 \const{SEGV\_ACCERR} & permessi non validi per l'indirizzo.\\
1992 \const{BUS\_ADRALN} & allineamento dell'indirizzo non valido.\\
1993 \const{BUS\_ADRERR} & indirizzo fisico inesistente.\\
1994 \const{BUS\_OBJERR} & errore hardware sull'indirizzo.\\
1996 \const{TRAP\_BRKPT} & breakpoint sul processo.\\
1997 \const{TRAP\_TRACE} & trappola di tracciamento del processo.\\
1999 \const{CLD\_EXITED} & il figlio è uscito.\\
2000 \const{CLD\_KILLED} & il figlio è stato terminato.\\
2001 \const{CLD\_DUMPED} & il figlio è terminato in modo anormale.\\
2002 \const{CLD\_TRAPPED} & un figlio tracciato ha raggiunto una trappola.\\
2003 \const{CLD\_STOPPED} & il figlio è stato fermato.\\
2004 \const{CLD\_CONTINUED}& il figlio è ripartito.\\
2006 \const{POLL\_IN} & disponibili dati in ingresso.\\
2007 \const{POLL\_OUT} & spazio disponibile sul buffer di uscita.\\
2008 \const{POLL\_MSG} & disponibili messaggi in ingresso.\\
2009 \const{POLL\_ERR} & errore di I/O.\\
2010 \const{POLL\_PRI} & disponibili dati di alta priorità in ingresso.\\
2011 \const{POLL\_HUP} & il dispositivo è stato disconnesso.\\
2014 \caption{Valori del campo \var{si\_code} della struttura \struct{sigaction}
2015 impostati rispettivamente dai segnali \signal{SIGILL}, \signal{SIGFPE},
2016 \signal{SIGSEGV}, \signal{SIGBUS}, \signal{SIGCHLD}, \signal{SIGTRAP} e
2017 \signal{SIGPOLL}/\signal{SIGIO}.}
2018 \label{tab:sig_si_code_special}
2021 Il resto della struttura \struct{siginfo\_t} è definito come \direct{union} ed i
2022 valori eventualmente presenti dipendono dal segnale, così \signal{SIGCHLD} ed i
2023 segnali \textit{real-time} (vedi sez.~\ref{sec:sig_real_time}) inviati tramite
2024 \func{kill} avvalorano \var{si\_pid} e \var{si\_uid} coi valori corrispondenti
2025 al processo che ha emesso il segnale, \signal{SIGCHLD} avvalora anche i campi
2026 \var{si\_status}, \var{si\_utime} e \var{si\_stime} che indicano
2027 rispettivamente lo stato di uscita, l'\textit{user time} e il \textit{system
2028 time} (vedi sez.~\ref{sec:sys_cpu_times}) usati dal processo;
2029 \signal{SIGILL}, \signal{SIGFPE}, \signal{SIGSEGV} e \signal{SIGBUS} avvalorano
2030 \var{si\_addr} con l'indirizzo in cui è avvenuto l'errore, \signal{SIGIO} (vedi
2031 sez.~\ref{sec:file_asyncronous_io}) avvalora \var{si\_fd} con il numero del
2032 file descriptor e \var{si\_band} per i \itindex{out-of-band} dati urgenti
2033 (vedi sez.~\ref{sec:TCP_urgent_data}) su un socket, il segnale inviato alla
2034 scadenza di un timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}) avvalora i
2035 campi \var{si\_timerid} e \var{si\_overrun}.
2037 Benché sia possibile usare nello stesso programma sia \func{sigaction} che
2038 \func{signal} occorre molta attenzione, in quanto le due funzioni possono
2039 interagire in maniera anomala. Infatti l'azione specificata con
2040 \struct{sigaction} contiene un maggior numero di informazioni rispetto al
2041 semplice indirizzo del gestore restituito da \func{signal}. Per questo motivo
2042 se si usa quest'ultima per installare un gestore sostituendone uno
2043 precedentemente installato con \func{sigaction}, non sarà possibile effettuare
2044 un ripristino corretto dello stesso.
2046 Per questo è sempre opportuno usare \func{sigaction}, che è in grado di
2047 ripristinare correttamente un gestore precedente, anche se questo è stato
2048 installato con \func{signal}. In generale poi non è il caso di usare il valore
2049 di ritorno di \func{signal} come campo \var{sa\_handler}, o viceversa, dato
2050 che in certi sistemi questi possono essere diversi. In definitiva dunque, a
2051 meno che non si sia vincolati all'aderenza stretta allo standard ISO C, è
2052 sempre il caso di evitare l'uso di \func{signal} a favore di \func{sigaction}.
2054 \begin{figure}[!htbp]
2055 \footnotesize \centering
2056 \begin{minipage}[c]{\codesamplewidth}
2057 \includecodesample{listati/Signal.c}
2060 \caption{La funzione \func{Signal}, equivalente a \func{signal}, definita
2061 attraverso \func{sigaction}.}
2062 \label{fig:sig_Signal_code}
2065 Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
2066 che abbia le stesse caratteristiche di \func{signal}, a definire attraverso
2067 \func{sigaction} una funzione equivalente \func{Signal}, il cui codice è
2068 riportato in fig.~\ref{fig:sig_Signal_code} (il codice completo si trova nel
2069 file \file{SigHand.c} nei sorgenti allegati). Si noti come, essendo la
2070 funzione estremamente semplice, essa è definita come
2071 \direct{inline};\footnote{la direttiva \direct{inline} viene usata per dire al
2072 compilatore di trattare la funzione cui essa fa riferimento in maniera
2073 speciale inserendo il codice direttamente nel testo del programma. Anche se
2074 i compilatori più moderni sono in grado di effettuare da soli queste
2075 manipolazioni (impostando le opportune ottimizzazioni) questa è una tecnica
2076 usata per migliorare le prestazioni per le funzioni piccole ed usate di
2077 frequente (in particolare nel kernel, dove in certi casi le ottimizzazioni
2078 dal compilatore, tarate per l'uso in user space, non sono sempre adatte). In
2079 tal caso infatti le istruzioni per creare un nuovo frame nello
2080 \itindex{stack} \textit{stack} per chiamare la funzione costituirebbero una
2081 parte rilevante del codice, appesantendo inutilmente il programma.
2082 Originariamente questo comportamento veniva ottenuto con delle macro, ma
2083 queste hanno tutta una serie di problemi di sintassi nel passaggio degli
2084 argomenti (si veda ad esempio \cite{PratC}) che in questo modo possono
2085 essere evitati.} per semplificare ulteriormente la definizione si è poi
2086 definito un apposito tipo \texttt{SigFunc}.
2090 \subsection{La gestione della \textsl{maschera dei segnali} o
2091 \textit{signal mask}}
2092 \label{sec:sig_sigmask}
2094 \itindbeg{signal~mask}
2095 Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like
2096 permettono di bloccare temporaneamente (o di eliminare completamente,
2097 impostando \const{SIG\_IGN} come azione) la consegna dei segnali ad un
2098 processo. Questo è fatto specificando la cosiddetta \textsl{maschera dei
2099 segnali} (o \textit{signal mask}) del processo\footnote{nel caso di Linux
2100 essa è mantenuta dal campo \var{blocked} della \struct{task\_struct} del
2101 processo.} cioè l'insieme dei segnali la cui consegna è bloccata. Abbiamo
2102 accennato in sez.~\ref{sec:proc_fork} che la \textit{signal mask} viene
2103 ereditata dal padre alla creazione di un processo figlio, e abbiamo visto al
2104 paragrafo precedente che essa può essere modificata, durante l'esecuzione di
2105 un gestore, attraverso l'uso dal campo \var{sa\_mask} di \struct{sigaction}.
2107 Uno dei problemi evidenziatisi con l'esempio di fig.~\ref{fig:sig_event_wrong}
2108 è che in molti casi è necessario proteggere delle sezioni di codice (nel caso
2109 in questione la sezione fra il controllo e la eventuale cancellazione del flag
2110 che testimoniava l'avvenuta occorrenza del segnale) in modo da essere sicuri
2111 che essi siano eseguite senza interruzioni.
2113 Le operazioni più semplici, come l'assegnazione o il controllo di una
2114 variabile (per essere sicuri si può usare il tipo \type{sig\_atomic\_t}) di
2115 norma sono atomiche; quando si devono eseguire operazioni più complesse si può
2116 invece usare la funzione \funcd{sigprocmask} che permette di bloccare uno o
2117 più segnali; il suo prototipo è:
2118 \begin{prototype}{signal.h}
2119 {int sigprocmask(int how, const sigset\_t *set, sigset\_t *oldset)}
2121 Cambia la \textsl{maschera dei segnali} del processo corrente.
2123 \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
2124 errore, nel qual caso \var{errno} assumerà i valori:
2126 \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
2127 \item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
2131 La funzione usa l'insieme di segnali dato all'indirizzo \param{set} per
2132 modificare la maschera dei segnali del processo corrente. La modifica viene
2133 effettuata a seconda del valore dell'argomento \param{how}, secondo le modalità
2134 specificate in tab.~\ref{tab:sig_procmask_how}. Qualora si specifichi un valore
2135 non nullo per \param{oldset} la maschera dei segnali corrente viene salvata a
2141 \begin{tabular}[c]{|l|p{8cm}|}
2143 \textbf{Valore} & \textbf{Significato} \\
2146 \const{SIG\_BLOCK} & L'insieme dei segnali bloccati è l'unione fra
2147 quello specificato e quello corrente.\\
2148 \const{SIG\_UNBLOCK} & I segnali specificati in \param{set} sono rimossi
2149 dalla maschera dei segnali, specificare la
2150 cancellazione di un segnale non bloccato è legale.\\
2151 \const{SIG\_SETMASK} & La maschera dei segnali è impostata al valore
2152 specificato da \param{set}.\\
2155 \caption{Valori e significato dell'argomento \param{how} della funzione
2156 \func{sigprocmask}.}
2157 \label{tab:sig_procmask_how}
2160 In questo modo diventa possibile proteggere delle sezioni di codice bloccando
2161 l'insieme di segnali voluto per poi riabilitarli alla fine della
2162 \index{sezione~critica} sezione critica. La funzione permette di risolvere
2163 problemi come quelli mostrati in fig.~\ref{fig:sig_event_wrong}, proteggendo
2164 la sezione fra il controllo del flag e la sua cancellazione.
2166 La funzione può essere usata anche all'interno di un gestore, ad esempio
2167 per riabilitare la consegna del segnale che l'ha invocato, in questo caso però
2168 occorre ricordare che qualunque modifica alla maschera dei segnali viene
2169 perduta alla conclusione del terminatore.
2171 Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
2172 dei casi di \itindex{race~condition} \textit{race condition} restano aperte
2173 alcune possibilità legate all'uso di \func{pause}; il caso è simile a quello
2174 del problema illustrato nell'esempio di fig.~\ref{fig:sig_sleep_incomplete}, e
2175 cioè la possibilità che il processo riceva il segnale che si intende usare per
2176 uscire dallo stato di attesa invocato con \func{pause} immediatamente prima
2177 dell'esecuzione di quest'ultima. Per poter effettuare atomicamente la modifica
2178 della maschera dei segnali (di solito attivandone uno specifico) insieme alla
2179 sospensione del processo lo standard POSIX ha previsto la funzione
2180 \funcd{sigsuspend}, il cui prototipo è:
2181 \begin{prototype}{signal.h}
2182 {int sigsuspend(const sigset\_t *mask)}
2184 Imposta la \textit{signal mask} specificata, mettendo in attesa il processo.
2186 \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
2187 errore, nel qual caso \var{errno} assumerà i valori:
2189 \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
2190 \item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
2194 Come esempio dell'uso di queste funzioni proviamo a riscrivere un'altra volta
2195 l'esempio di implementazione di \code{sleep}. Abbiamo accennato in
2196 sez.~\ref{sec:sig_sigaction} come con \func{sigaction} sia possibile bloccare
2197 \signal{SIGALRM} nell'installazione dei gestori degli altri segnali, per poter
2198 usare l'implementazione vista in fig.~\ref{fig:sig_sleep_incomplete} senza
2199 interferenze. Questo però comporta una precauzione ulteriore al semplice uso
2200 della funzione, vediamo allora come usando la nuova interfaccia è possibile
2201 ottenere un'implementazione, riportata in fig.~\ref{fig:sig_sleep_ok} che non
2202 presenta neanche questa necessità.
2204 \begin{figure}[!htbp]
2205 \footnotesize \centering
2206 \begin{minipage}[c]{\codesamplewidth}
2207 \includecodesample{listati/sleep.c}
2210 \caption{Una implementazione completa di \func{sleep}.}
2211 \label{fig:sig_sleep_ok}
2214 Per evitare i problemi di interferenza con gli altri segnali in questo caso
2215 non si è usato l'approccio di fig.~\ref{fig:sig_sleep_incomplete} evitando
2216 l'uso di \func{longjmp}. Come in precedenza il gestore (\texttt{\small 27-30})
2217 non esegue nessuna operazione, limitandosi a ritornare per interrompere il
2218 programma messo in attesa.
2220 La prima parte della funzione (\texttt{\small 6-10}) provvede ad installare
2221 l'opportuno gestore per \signal{SIGALRM}, salvando quello originario, che
2222 sarà ripristinato alla conclusione della stessa (\texttt{\small 23}); il passo
2223 successivo è quello di bloccare \signal{SIGALRM} (\texttt{\small 11-14}) per
2224 evitare che esso possa essere ricevuto dal processo fra l'esecuzione di
2225 \func{alarm} (\texttt{\small 16}) e la sospensione dello stesso. Nel fare
2226 questo si salva la maschera corrente dei segnali, che sarà ripristinata alla
2227 fine (\texttt{\small 22}), e al contempo si prepara la maschera dei segnali
2228 \var{sleep\_mask} per riattivare \signal{SIGALRM} all'esecuzione di
2231 In questo modo non sono più possibili \itindex{race~condition} \textit{race
2232 condition} dato che \signal{SIGALRM} viene disabilitato con
2233 \func{sigprocmask} fino alla chiamata di \func{sigsuspend}. Questo metodo è
2234 assolutamente generale e può essere applicato a qualunque altra situazione in
2235 cui si deve attendere per un segnale, i passi sono sempre i seguenti:
2237 \item leggere la maschera dei segnali corrente e bloccare il segnale voluto
2238 con \func{sigprocmask};
2239 \item mandare il processo in attesa con \func{sigsuspend} abilitando la
2240 ricezione del segnale voluto;
2241 \item ripristinare la maschera dei segnali originaria.
2243 Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi
2244 riabilitarla immediatamente dopo, in questo modo si evita il
2245 \itindex{deadlock} deadlock dovuto all'arrivo del segnale prima
2246 dell'esecuzione di \func{sigsuspend}.
2248 \itindend{signal~mask}
2251 \subsection{Criteri di programmazione per i gestori dei segnali}
2252 \label{sec:sig_signal_handler}
2254 Abbiamo finora parlato dei gestori dei segnali come funzioni chiamate in
2255 corrispondenza della consegna di un segnale. In realtà un gestore non può
2256 essere una funzione qualunque, in quanto esso può essere eseguito in
2257 corrispondenza all'interruzione in un punto qualunque del programma
2258 principale, cosa che ad esempio può rendere problematico chiamare all'interno
2259 di un gestore di segnali la stessa funzione che dal segnale è stata
2262 \index{funzioni!sicure|(}
2264 Il concetto è comunque più generale e porta ad una distinzione fra quelle che
2265 POSIX chiama \textsl{funzioni insicure} (\textit{signal unsafe function}) e
2266 \textsl{funzioni sicure} (o più precisamente \textit{signal safe function});
2267 quando un segnale interrompe una funzione insicura ed il gestore chiama al suo
2268 interno una funzione insicura il sistema può dare luogo ad un comportamento
2269 indefinito, la cosa non avviene invece per le funzioni sicure.
2271 Tutto questo significa che la funzione che si usa come gestore di segnale deve
2272 essere programmata con molta cura per evirare questa evenienza e che non è
2273 possibile utilizzare al suo interno una qualunque funzione di sistema, se si
2274 vogliono evitare questi problemi si può ricorrere soltanto all'uso delle
2275 funzioni considerate sicure.
2277 L'elenco delle funzioni considerate sicure varia a seconda della
2278 implementazione utilizzata e dello standard a cui si fa
2279 riferimento;\footnote{non è riportata una lista specifica delle funzioni
2280 sicure per Linux, si suppone pertanto che siano quelle richieste dallo
2281 standard.} secondo quanto riportato dallo standard POSIX 1003.1 nella
2282 revisione del 2003, le ``\textit{signal safe function}'' che possono essere
2283 chiamate anche all'interno di un gestore di segnali sono tutte quelle della
2284 lista riportata in fig.~\ref{fig:sig_safe_functions}.
2286 \begin{figure}[!htb]
2287 \footnotesize \centering
2288 \begin{minipage}[c]{14cm}
2289 \func{\_exit}, \func{abort}, \func{accept}, \func{access},
2290 \func{aio\_error} \func{aio\_return}, \func{aio\_suspend}, \func{alarm},
2291 \func{bind}, \func{cfgetispeed}, \func{cfgetospeed}, \func{cfsetispeed},
2292 \func{cfsetospeed}, \func{chdir}, \func{chmod}, \func{chown},
2293 \func{clock\_gettime}, \func{close}, \func{connect}, \func{creat},
2294 \func{dup}, \func{dup2}, \func{execle}, \func{execve}, \func{fchmod},
2295 \func{fchown}, \func{fcntl}, \func{fdatasync}, \func{fork},
2296 \func{fpathconf}, \func{fstat}, \func{fsync}, \func{ftruncate},
2297 \func{getegid}, \func{geteuid}, \func{getgid}, \func{getgroups},
2298 \func{getpeername}, \func{getpgrp}, \func{getpid}, \func{getppid},
2299 \func{getsockname}, \func{getsockopt}, \func{getuid}, \func{kill},
2300 \func{link}, \func{listen}, \func{lseek}, \func{lstat}, \func{mkdir},
2301 \func{mkfifo}, \func{open}, \func{pathconf}, \func{pause}, \func{pipe},
2302 \func{poll}, \funcm{posix\_trace\_event}, \func{pselect}, \func{raise},
2303 \func{read}, \func{readlink}, \func{recv}, \func{recvfrom},
2304 \func{recvmsg}, \func{rename}, \func{rmdir}, \func{select},
2305 \func{sem\_post}, \func{send}, \func{sendmsg}, \func{sendto},
2306 \func{setgid}, \func{setpgid}, \func{setsid}, \func{setsockopt},
2307 \func{setuid}, \func{shutdown}, \func{sigaction}, \func{sigaddset},
2308 \func{sigdelset}, \func{sigemptyset}, \func{sigfillset},
2309 \func{sigismember}, \func{signal}, \func{sigpause}, \func{sigpending},
2310 \func{sigprocmask}, \func{sigqueue}, \funcm{sigset}, \func{sigsuspend},
2311 \func{sleep}, \func{socket}, \func{socketpair}, \func{stat},
2312 \func{symlink}, \func{sysconf}, \func{tcdrain}, \func{tcflow},
2313 \func{tcflush}, \func{tcgetattr}, \func{tcgetgrp}, \func{tcsendbreak},
2314 \func{tcsetattr}, \func{tcsetpgrp}, \func{time}, \func{timer\_getoverrun},
2315 \func{timer\_gettime}, \func{timer\_settime}, \func{times}, \func{umask},
2316 \func{uname}, \func{unlink}, \func{utime}, \func{wait}, \func{waitpid},
2320 \caption{Elenco delle funzioni sicure secondo lo standard POSIX
2322 \label{fig:sig_safe_functions}
2325 \index{funzioni!sicure|)}
2327 Lo standard POSIX.1-2004 modifica la lista di
2328 fig.~\ref{fig:sig_safe_functions} aggiungendo le funzioni \func{\_Exit} e
2329 \func{sockatmark}, mentre lo standard POSIX.1-2008 rimuove della lista le tre
2330 funzioni \func{fpathconf}, \func{pathconf}, \func{sysconf} e vi aggiunge le
2331 ulteriori funzioni in fig.~\ref{fig:sig_safe_functions_posix_2008}.
2333 \begin{figure}[!htb]
2334 \footnotesize \centering
2335 \begin{minipage}[c]{14cm}
2336 \func{execl}, \func{execv}, \func{faccessat}, \func{fchmodat},
2337 \func{fchownat}, \func{fexecve}, \func{fstatat}, \func{futimens},
2338 \func{linkat}, \func{mkdirat}, \func{mkfifoat}, \func{mknod},
2339 \func{mknodat}, \func{openat}, \func{readlinkat}, \func{renameat},
2340 \func{symlinkat}, \func{unlinkat}, \func{utimensat}, \func{utimes}.
2343 \caption{Ulteriori funzioni sicure secondo lo standard POSIX.1-2008.}
2344 \label{fig:sig_safe_functions_posix_2008}
2348 Per questo motivo è opportuno mantenere al minimo indispensabile le operazioni
2349 effettuate all'interno di un gestore di segnali, qualora si debbano compiere
2350 operazioni complesse è sempre preferibile utilizzare la tecnica in cui si usa
2351 il gestore per impostare il valore di una qualche \index{variabili!globali}
2352 variabile globale, e poi si eseguono le operazioni complesse nel programma
2353 verificando (con tutti gli accorgimenti visti in precedenza) il valore di
2354 questa variabile tutte le volte che si è rilevata una interruzione dovuta ad
2358 \section{Funzionalità avanzate}
2359 \label{sec:sig_advanced_signal}
2362 Tratteremo in questa ultima sezione alcune funzionalità avanzate relativa ai
2363 segnali ed in generale ai meccanismi di notifica, a partire dalla funzioni
2364 introdotte per la gestione dei cosiddetti ``\textsl{segnali real-time}'', alla
2365 gestione avanzata delle temporizzazioni e le nuove interfacce per la gestione
2366 di segnali ed eventi attraverso l'uso di file descriptor.
2368 \subsection{I segnali \textit{real-time}}
2369 \label{sec:sig_real_time}
2371 Lo standard POSIX.1b, nel definire una serie di nuove interfacce per i servizi
2372 \textit{real-time}, ha introdotto una estensione del modello classico dei
2373 segnali che presenta dei significativi miglioramenti,\footnote{questa
2374 estensione è stata introdotta in Linux a partire dal kernel 2.1.43, e dalle
2375 \acr{glibc} 2.1.} in particolare sono stati superati tre limiti fondamentali
2376 dei segnali classici:
2377 \begin{basedescript}{\desclabelwidth{1cm}\desclabelstyle{\nextlinelabel}}
2378 \item[I segnali non sono accumulati]
2379 se più segnali vengono generati prima dell'esecuzione di un gestore
2380 questo sarà eseguito una sola volta, ed il processo non sarà in grado di
2381 accorgersi di quante volte l'evento che ha generato il segnale è accaduto;
2382 \item[I segnali non trasportano informazione]
2383 i segnali classici non prevedono altra informazione sull'evento
2384 che li ha generati se non il fatto che sono stati emessi (tutta
2385 l'informazione che il kernel associa ad un segnale è il suo numero);
2386 \item[I segnali non hanno un ordine di consegna]
2387 l'ordine in cui diversi segnali vengono consegnati è casuale e non
2388 prevedibile. Non è possibile stabilire una priorità per cui la reazione a
2389 certi segnali ha la precedenza rispetto ad altri.
2392 Per poter superare queste limitazioni lo standard POSIX.1b ha introdotto delle
2393 nuove caratteristiche, che sono state associate ad una nuova classe di
2394 segnali, che vengono chiamati \textsl{segnali real-time}, in particolare le
2395 funzionalità aggiunte sono:
2398 \item i segnali sono inseriti in una coda che permette di consegnare istanze
2399 multiple dello stesso segnale qualora esso venga inviato più volte prima
2400 dell'esecuzione del gestore; si assicura così che il processo riceva un
2401 segnale per ogni occorrenza dell'evento che lo genera.
2402 \item è stata introdotta una priorità nella consegna dei segnali: i segnali
2403 vengono consegnati in ordine a seconda del loro valore, partendo da quelli
2404 con un numero minore, che pertanto hanno una priorità maggiore.
2405 \item è stata introdotta la possibilità di restituire dei dati al gestore,
2406 attraverso l'uso di un apposito campo \var{si\_value} nella struttura
2407 \struct{siginfo\_t}, accessibile tramite gestori di tipo
2408 \var{sa\_sigaction}.
2411 Tutte queste nuove funzionalità eccetto l'ultima, che, come illustrato in
2412 sez.~\ref{sec:sig_sigaction}, è disponibile anche con i segnali ordinari, si
2413 applicano solo ai nuovi segnali \textit{real-time}; questi ultimi sono
2414 accessibili in un intervallo di valori specificati dalle due costanti
2415 \const{SIGRTMIN} e \const{SIGRTMAX}, che specificano il numero minimo e
2416 massimo associato ad un segnale \textit{real-time}.
2418 Su Linux di solito il primo valore è 33, mentre il secondo è \code{\_NSIG-1},
2419 che di norma (vale a dire sulla piattaforma i386) è 64. Questo dà un totale di
2420 32 segnali disponibili, contro gli almeno 8 richiesti da POSIX.1b. Si tenga
2421 presente però che i primi segnali \textit{real-time} disponibili vendono usati
2422 dalle \acr{glibc} per l'implementazione dei \textit{thread} POSIX (vedi
2423 sez.~\ref{sec:thread_posix_intro}), ed il valore di \const{SIGRTMIN} viene
2424 modificato di conseguenza.\footnote{vengono usati i primi tre per la vecchia
2425 implementazione dei \textit{LinuxThread} ed i primi due per la nuova NTPL
2426 (\textit{New Thread Posix Library}), il che comporta che \const{SIGRTMIN} a
2427 seconda dei casi può essere 34 o 35.}
2429 Per questo motivo nei programmi che usano i segnali \textit{real-time} non si
2430 deve mai usare un valore assoluto dato che si correrebbe il rischio di
2431 utilizzare un segnale in uso alle librerie, ed il numero del segnale deve
2432 invece essere sempre specificato in forma relativa a \const{SIGRTMIN} (come
2433 \code{SIGRTMIN + n}) avendo inoltre cura di controllare di non aver mai
2434 superato \const{SIGRTMAX}.
2436 I segnali con un numero più basso hanno una priorità maggiore e vengono
2437 consegnati per primi, inoltre i segnali \textit{real-time} non possono
2438 interrompere l'esecuzione di un gestore di un segnale a priorità più alta; la
2439 loro azione predefinita è quella di terminare il programma. I segnali
2440 ordinari hanno tutti la stessa priorità, che è più alta di quella di qualunque
2441 segnale \textit{real-time}.\footnote{lo standard non definisce niente al
2442 riguardo ma Linux, come molte altre implementazioni, adotta questa
2445 Si tenga presente che questi nuovi segnali non sono associati a nessun evento
2446 specifico, a meno di non richiedere specificamente il loro utilizzo in
2447 meccanismi di notifica come quelli per l'I/O asincrono (vedi
2448 sez.~\ref{sec:file_asyncronous_io}) o per le code di messaggi POSIX (vedi
2449 sez.~\ref{sec:ipc_posix_mq}); pertanto devono essere inviati esplicitamente.
2451 Inoltre, per poter usufruire della capacità di restituire dei dati, i relativi
2452 gestori devono essere installati con \func{sigaction}, specificando per
2453 \var{sa\_flags} la modalità \const{SA\_SIGINFO} che permette di utilizzare la
2454 forma estesa \var{sa\_sigaction} (vedi sez.~\ref{sec:sig_sigaction}). In
2455 questo modo tutti i segnali \textit{real-time} possono restituire al gestore
2456 una serie di informazioni aggiuntive attraverso l'argomento
2457 \struct{siginfo\_t}, la cui definizione è stata già vista in
2458 fig.~\ref{fig:sig_siginfo_t}, nella trattazione dei gestori in forma estesa.
2460 In particolare i campi utilizzati dai segnali \textit{real-time} sono
2461 \var{si\_pid} e \var{si\_uid} in cui vengono memorizzati rispettivamente il
2462 \ids{PID} e l'\ids{UID} effettivo del processo che ha inviato il segnale, mentre
2463 per la restituzione dei dati viene usato il campo \var{si\_value}.
2465 \begin{figure}[!htb]
2466 \footnotesize \centering
2467 \begin{minipage}[c]{\textwidth}
2468 \includestruct{listati/sigval_t.h}
2471 \caption{La definizione dell'unione \structd{sigval}, definita anche come
2472 tipo \type{sigval\_t}.}
2473 \label{fig:sig_sigval}
2476 Questo è una \direct{union} di tipo \struct{sigval} (la sua definizione è in
2477 fig.~\ref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico,
2478 se usata nella forma \var{sival\_int}, o un indirizzo, se usata nella forma
2479 \var{sival\_ptr}. L'unione viene usata dai segnali \textit{real-time} e da
2480 vari meccanismi di notifica\footnote{un campo di tipo \type{sigval\_t} è
2481 presente anche nella struttura \struct{sigevent} (definita in
2482 fig.~\ref{fig:struct_sigevent}) che viene usata dai meccanismi di notifica
2483 come quelli per i timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}), l'I/O
2484 asincrono (vedi sez.~\ref{sec:file_asyncronous_io}) o le code di messaggi
2485 POSIX (vedi sez.~\ref{sec:ipc_posix_mq}).} per restituire dati al gestore
2486 del segnale; in alcune definizioni essa viene identificata anche con
2487 l'abbreviazione \type{sigval\_t}.
2489 A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
2490 inviare segnali \textit{real-time}, poiché non è in grado di fornire alcun
2491 valore per \struct{sigval}; per questo motivo lo standard ha previsto una
2492 nuova funzione, \funcd{sigqueue}, il cui prototipo è:
2493 \begin{prototype}{signal.h}
2494 {int sigqueue(pid\_t pid, int signo, const union sigval value)}
2496 Invia il segnale \param{signo} al processo \param{pid}, restituendo al
2497 gestore il valore \param{value}.
2499 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
2500 errore, nel qual caso \var{errno} assumerà uno dei valori:
2502 \item[\errcode{EAGAIN}] la coda è esaurita, ci sono già
2503 \const{SIGQUEUE\_MAX} segnali in attesa si consegna.
2504 \item[\errcode{EPERM}] non si hanno privilegi appropriati per inviare il
2505 segnale al processo specificato.
2506 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2507 \item[\errcode{EINVAL}] si è specificato un valore non valido per
2510 ed inoltre \errval{ENOMEM}.}
2513 Il comportamento della funzione è analogo a quello di \func{kill}, ed i
2514 privilegi occorrenti ad inviare il segnale ad un determinato processo sono gli
2515 stessi; un valore nullo di \param{signo} permette di verificare le condizioni
2516 di errore senza inviare nessun segnale.
2518 Se il segnale è bloccato la funzione ritorna immediatamente, se si è
2519 installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili,
2520 (vale a dire che c'è posto nella coda dei segnali \textit{real-time}) esso
2521 viene inserito e diventa pendente; una volta consegnato riporterà nel campo
2522 \var{si\_code} di \struct{siginfo\_t} il valore \const{SI\_QUEUE} e il campo
2523 \var{si\_value} riceverà quanto inviato con \param{value}. Se invece si è
2524 installato un gestore nella forma classica il segnale sarà generato, ma tutte
2525 le caratteristiche tipiche dei segnali \textit{real-time} (priorità e coda)
2528 Secondo lo standard POSIX la profondità della coda è indicata dalla costante
2529 \const{SIGQUEUE\_MAX},\footnote{una della tante costanti di sistema definite
2530 dallo standard POSIX che non abbiamo riportato esplicitamente in
2531 sez.~\ref{sec:sys_limits}.} il suo valore minimo secondo lo standard,
2532 \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux la coda ha una
2533 dimensione variabile; fino alla versione 2.6.7 c'era un limite massimo globale
2534 che poteva essere impostato come parametro del kernel in
2535 \sysctlfile{kernel/rtsig-max};\footnote{ed il valore predefinito era
2536 pari a 1024.} a partire dal kernel 2.6.8 il valore globale è stato rimosso e
2537 sostituito dalla risorsa \const{RLIMIT\_SIGPENDING} associata al singolo
2538 utente, che può essere modificata con \func{setrlimit} come illustrato in
2539 sez.~\ref{sec:sys_resource_limit}.
2541 Lo standard POSIX.1b definisce inoltre delle nuove funzioni che permettono di
2542 gestire l'attesa di segnali specifici su una coda, esse servono in particolar
2543 modo nel caso dei \itindex{thread} \textit{thread}, in cui si possono usare i
2544 segnali \textit{real-time} come meccanismi di comunicazione elementare; la
2545 prima di queste funzioni è \funcd{sigwait}, il cui prototipo è:
2546 \begin{prototype}{signal.h}
2547 {int sigwait(const sigset\_t *set, int *sig)}
2549 Attende che uno dei segnali specificati in \param{set} sia pendente.
2551 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
2552 errore, nel qual caso \var{errno} assumerà uno dei valori:
2554 \item[\errcode{EINTR}] la funzione è stata interrotta.
2555 \item[\errcode{EINVAL}] si è specificato un valore non valido per
2558 ed inoltre \errval{EFAULT}.}
2561 La funzione estrae dall'insieme dei segnali pendenti uno qualunque dei segnali
2562 specificati da \param{set}, il cui valore viene restituito in \param{sig}. Se
2563 sono pendenti più segnali, viene estratto quello a priorità più alta (cioè con
2564 il numero più basso). Se, nel caso di segnali \textit{real-time}, c'è più di
2565 un segnale pendente, ne verrà estratto solo uno. Una volta estratto il segnale
2566 non verrà più consegnato, e se era in una coda il suo posto sarà liberato. Se
2567 non c'è nessun segnale pendente il processo viene bloccato fintanto che non ne
2570 Per un funzionamento corretto la funzione richiede che alla sua chiamata i
2571 segnali di \param{set} siano bloccati. In caso contrario si avrebbe un
2572 conflitto con gli eventuali gestori: pertanto non si deve utilizzare per
2573 lo stesso segnale questa funzione e \func{sigaction}. Se questo non avviene il
2574 comportamento del sistema è indeterminato: il segnale può sia essere
2575 consegnato che essere ricevuto da \func{sigwait}, il tutto in maniera non
2578 Lo standard POSIX.1b definisce altre due funzioni, anch'esse usate
2579 prevalentemente con i \itindex{thread} \textit{thread}; \funcd{sigwaitinfo} e
2580 \funcd{sigtimedwait}, i relativi prototipi sono:
2584 \funcdecl{int sigwaitinfo(const sigset\_t *set, siginfo\_t *info)}
2586 Analoga a \func{sigwait}, ma riceve anche le informazioni associate al
2587 segnale in \param{info}.
2589 \funcdecl{int sigtimedwait(const sigset\_t *set, siginfo\_t *info, const
2590 struct timespec *timeout)}
2592 Analoga a \func{sigwaitinfo}, con un la possibilità di specificare un
2593 timeout in \param{timeout}.
2596 \bodydesc{Le funzioni restituiscono 0 in caso di successo e $-1$ in caso di
2597 errore, nel qual caso \var{errno} assumerà uno dei valori già visti per
2598 \func{sigwait}, ai quali si aggiunge, per \func{sigtimedwait}:
2600 \item[\errcode{EAGAIN}] si è superato il timeout senza che un segnale atteso
2606 Entrambe le funzioni sono estensioni di \func{sigwait}. La prima permette di
2607 ricevere, oltre al numero del segnale, anche le informazioni ad esso associate
2608 tramite \param{info}; in particolare viene restituito il numero del segnale
2609 nel campo \var{si\_signo}, la sua causa in \var{si\_code}, e se il segnale è
2610 stato immesso sulla coda con \func{sigqueue}, il valore di ritorno ad esso
2611 associato viene riportato in \var{si\_value}, che altrimenti è indefinito.
2613 La seconda è identica alla prima ma in più permette di specificare un timeout,
2614 scaduto il quale ritornerà con un errore. Se si specifica un puntatore nullo
2615 il comportamento sarà identico a \func{sigwaitinfo}, se si specifica un tempo
2616 di timeout nullo, e non ci sono segnali pendenti la funzione ritornerà
2617 immediatamente; in questo modo si può eliminare un segnale dalla coda senza
2618 dover essere bloccati qualora esso non sia presente.
2622 L'uso di queste funzioni è principalmente associato alla gestione dei segnali
2623 con i \textit{thread}. In genere esse vengono chiamate dal \textit{thread}
2624 incaricato della gestione, che al ritorno della funzione esegue il codice che
2625 usualmente sarebbe messo nel gestore, per poi ripetere la chiamata per
2626 mettersi in attesa del segnale successivo. Questo ovviamente comporta che non
2627 devono essere installati gestori, che solo il \textit{thread} di gestione deve
2628 usare \func{sigwait} e che i segnali gestiti in questa maniera, per evitare
2629 che venga eseguita l'azione predefinita, devono essere mascherati per tutti i
2630 \textit{thread}, compreso quello dedicato alla gestione, che potrebbe
2631 riceverlo fra due chiamate successive.
2636 \subsection{La gestione avanzata delle temporizzazioni}
2637 \label{sec:sig_timer_adv}
2639 Sia le funzioni per la gestione dei tempi viste in
2640 sez.~\ref{sec:sys_cpu_times} che quelle per la gestione dei timer di
2641 sez.~\ref{sec:sig_alarm_abort} sono state a lungo limitate dalla risoluzione
2642 massima dei tempi dell'orologio interno del kernel, che era quella ottenibile
2643 dal timer di sistema che governa lo \textit{scheduler},\footnote{e quindi
2644 limitate dalla frequenza dello stesso che si ricordi, come già illustrato in
2645 sez.~\ref{sec:proc_hierarchy}, è data dal valore della costante
2646 \texttt{HZ}.} i contatori usati per il calcolo dei tempi infatti erano
2647 basati sul numero di \itindex{jiffies} \textit{jiffies} che vengono
2648 incrementati ad ogni \textit{clock tick} del timer di sistema.\footnote{il che
2649 comportava anche, come accennato in sez.~\ref{sec:sig_alarm_abort} per
2650 \func{setitimer}, problemi per il massimo periodo di tempo copribile da
2651 alcuni di questi orologi, come quelli associati al \textit{process time}
2652 almeno fino a quando, con il kernel 2.6.16, non è stato rimosso il limite di
2653 un valore a 32 bit per i \textit{jiffies}.}
2655 Nelle architetture moderne però tutti i computer sono dotati di temporizzatori
2656 hardware che possono supportare risoluzioni molto elevate, ed in maniera del
2657 tutto indipendente dalla frequenza scelta per il timer di sistema che governa
2658 lo \textit{scheduler};\footnote{normalmente si possono ottenere precisioni
2659 fino al microsecondo, andando molto oltre in caso di hardware dedicato.} per
2660 questo lo standard POSIX.1-2001 ha previsto una serie di nuove funzioni
2661 relative a quelli che vengono chiamati ``\textsl{orologi}
2662 \textit{real-time}'', in grado di supportare risoluzioni fino al
2663 nanosecondo. Inoltre le CPU più moderne sono dotate a loro volta di contatori
2664 ad alta definizione che consentono una grande accuratezza nella misura del
2665 tempo da esse dedicato all'esecuzione di un processo.
2667 Per usare queste funzionalità ed ottenere risoluzioni temporali più accurate,
2668 occorre però un opportuno supporto da parte del kernel, ed i cosiddetti
2669 \itindex{high~resolution~timer} \textit{high resolution timer} che consentono
2670 di fare ciò sono stati introdotti nel kernel ufficiale solo a partire dalla
2671 versione 2.6.21.\footnote{deve essere stata abilitata l'opzione di
2672 compilazione \texttt{CONFIG\_HIGH\_RES\_TIMERS}, erano però disponibili
2673 anche in precedenza come patch facenti parte dello sviluppo delle estensioni
2674 \textit{real-time} del kernel, per cui alcune distribuzioni possono avere
2675 questo supporto anche con versioni precedenti del kernel.} Le funzioni
2676 definite dallo standard POSIX per gestire orologi ad alta definizione però
2677 erano già presenti, essendo stata introdotte insieme ad altre funzioni per il
2678 supporto delle estensioni \textit{real-time} con il rilascio del kernel 2.6,
2679 ma la risoluzione effettiva era nominale.
2681 A tutte le implementazioni che si rifanno a queste estensioni è richiesto di
2682 disporre di una versione \textit{real-time} almeno per l'orologio generale di
2683 sistema, quello che mantiene il \textit{calendar time} (vedi
2684 sez.~\ref{sec:sys_time_base}), che in questa forma deve indicare il numero di
2685 secondi e nanosecondi passati a partire dal primo gennaio 1970 (\textit{The
2686 Epoch}).\footnote{si ricordi che l'orologio ordinario usato dal
2687 \textit{calendar time} riporta solo un numero di secondi, e che la
2688 risoluzione effettiva normalmente non raggiunge il nanosecondo (a meno di
2689 hardware specializzato).} Oltre all'orologio generale di sistema possono
2690 essere presenti altri tipi di orologi \textit{real-time}, ciascuno dei quali
2691 viene identificato da un opportuno valore di una variabile di tipo
2692 \type{clockid\_t}; un elenco di quelli disponibili su Linux è riportato in
2693 tab.~\ref{tab:sig_timer_clockid_types}.
2698 \begin{tabular}[c]{|l|p{8cm}|}
2700 \textbf{Valore} & \textbf{Significato} \\
2703 \const{CLOCK\_REALTIME} & Orologio \textit{real-time} di sistema, può
2704 essere impostato solo con privilegi
2706 \const{CLOCK\_MONOTONIC} & Orologio che indica un tempo monotono
2707 crescente (a partire da un tempo iniziale non
2708 specificato) che non può essere modificato e
2709 non cambia neanche in caso di reimpostazione
2710 dell'orologio di sistema.\\
2711 \const{CLOCK\_MONOTONIC\_RAW}&Simile al precedente, ma non subisce gli
2712 aggiustamenti dovuti all'uso di NTP (viene
2713 usato per fare riferimento ad una fonte
2714 hardware).\footnotemark\\
2715 \const{CLOCK\_PROCESS\_CPUTIME\_ID}& contatore del tempo di CPU usato
2716 da un processo (il \textit{process time} di
2717 sez.~\ref{sec:sys_cpu_times}, nel totale di
2718 \textit{system time} e \textit{user time})
2719 comprensivo di tutto il tempo di CPU usato
2720 da eventuali \itindex{thread}
2722 \const{CLOCK\_THREAD\_CPUTIME\_ID}& contatore del tempo di CPU
2723 (\textit{user time} e \textit{system time})
2724 usato da un singolo \itindex{thread}
2729 \caption{Valori possibili per una variabile di tipo \type{clockid\_t}
2730 usata per indicare a quale tipo di orologio si vuole fare riferimento.}
2731 \label{tab:sig_timer_clockid_types}
2734 \footnotetext{specifico di Linux, introdotto a partire dal kernel 2.6.28, non
2735 previsto da POSIX e non presente in altri sistemi unix-like.}
2737 % TODO: aggiungere le estensioni introdotte con il 2.6.38, verificandone il
2738 % funzionamento, vedi http://lwn.net/Articles/429595/
2739 % TODO: dal 2.6.39 anche CLOCK_BOOTTIME_ALARM e CLOCK_BOOTTIME, vedi
2740 % http://lwn.net/Articles/429925/
2741 % TODP: dal 3.0 anche i cosiddetti Posix Alarm Timers, con
2742 % CLOCK_REALTIME_ALARM vedi http://lwn.net/Articles/429925/
2744 Per poter utilizzare queste funzionalità le \acr{glibc} richiedono che la
2745 macro \macro{\_POSIX\_C\_SOURCE} sia definita ad un valore maggiore o uguale
2746 di \texttt{199309L} (vedi sez.~\ref{sec:intro_gcc_glibc_std}), inoltre i
2747 programmi che le usano devono essere collegati con la libreria delle
2748 estensioni \textit{real-time} usando esplicitamente l'opzione
2749 \texttt{-lrt}. Si tenga presente inoltre che la disponibilità di queste
2750 funzionalità avanzate può essere controllato dalla definizione della macro
2751 \macro{\_POSIX\_TIMERS} ad un valore maggiore di 0, e che le ulteriori macro
2752 \macro{\_POSIX\_MONOTONIC\_CLOCK}, \macro{\_POSIX\_CPUTIME} e
2753 \macro{\_POSIX\_THREAD\_CPUTIME} indicano la presenza dei rispettivi orologi
2754 di tipo \const{CLOCK\_MONOTONIC}, \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
2755 \const{CLOCK\_PROCESS\_CPUTIME\_ID}.\footnote{tutte queste macro sono definite
2756 in \headfile{unistd.h}, che pertanto deve essere incluso per poterle
2757 controllarle.} Infine se il kernel ha il supporto per gli \textit{high
2758 resolution timer} un elenco degli orologi e dei timer può essere ottenuto
2759 tramite il file \procfile{/proc/timer\_list}.
2761 Le due funzioni che ci consentono rispettivamente di modificare o leggere il
2762 valore per uno degli orologi \textit{real-time} sono \funcd{clock\_settime} e
2763 \funcd{clock\_gettime}; i rispettivi prototipi sono:
2767 \funcdecl{int clock\_settime(clockid\_t clockid, const struct timespec *tp)}
2768 \funcdecl{int clock\_gettime(clockid\_t clockid, struct timespec *tp)}
2770 Imposta o legge un orologio \textit{real-time}.
2772 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
2773 errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
2775 \item[\errcode{EINVAL}] il valore specificato per \param{clockid} non è
2776 valido o il relativo orologio \textit{real-time} non è supportato dal
2778 \item[\errcode{EPERM}] non si ha il permesso di impostare l'orologio
2779 indicato (solo per \func{clock\_settime}).
2780 \item[\errcode{EFAULT}] l'indirizzo \param{tp} non è valido.
2785 Entrambe le funzioni richiedono che si specifichi come primo argomento il tipo
2786 di orologio su cui si vuole operare con uno dei valori di
2787 tab.~\ref{tab:sig_timer_clockid_types} o con il risultato di una chiamata a
2788 \func{clock\_getcpuclockid} (che tratteremo a breve), il secondo argomento
2789 invece è sempre il puntatore \param{tp} ad una struttura \struct{timespec}
2790 (vedi fig.~\ref{fig:sys_timespec_struct}) che deve essere stata
2791 precedentemente allocata; nel primo caso questa dovrà anche essere stata
2792 inizializzata con il valore che si vuole impostare sull'orologio, mentre nel
2793 secondo verrà restituito al suo interno il valore corrente dello stesso.
2795 Si tenga presente inoltre che per eseguire un cambiamento sull'orologio
2796 generale di sistema \const{CLOCK\_REALTIME} occorrono i privilegi
2797 amministrativi;\footnote{ed in particolare la \textit{capability}
2798 \const{CAP\_SYS\_TIME}.} inoltre ogni cambiamento ad esso apportato non avrà
2799 nessun effetto sulle temporizzazioni effettuate in forma relativa, come quelle
2800 impostate sulle quantità di \textit{process time} o per un intervallo di tempo
2801 da trascorrere, ma solo su quelle che hanno richiesto una temporizzazione ad
2802 un istante preciso (in termini di \textit{calendar time}). Si tenga inoltre
2803 presente che nel caso di Linux \const{CLOCK\_REALTIME} è l'unico orologio per
2804 cui si può effettuare una modifica, infatti nonostante lo standard preveda la
2805 possibilità di modifiche anche per \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
2806 \const{CLOCK\_THREAD\_CPUTIME\_ID}, il kernel non le consente.
2808 Oltre alle due funzioni precedenti, lo standard POSIX prevede una terza
2809 funzione che consenta di ottenere la risoluzione effettiva fornita da un certo
2810 orologio, la funzione è \funcd{clock\_getres} ed il suo prototipo è:
2814 \funcdecl{int clock\_getres(clockid\_t clockid, struct timespec *res)}
2816 Legge la risoluzione di un orologio \textit{real-time}.
2818 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
2819 errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
2821 \item[\errcode{EINVAL}] il valore specificato per \param{clockid} non è
2823 \item[\errcode{EFAULT}] l'indirizzo di \param{res} non è valido.
2828 La funzione richiede come primo argomento l'indicazione dell'orologio di cui
2829 si vuole conoscere la risoluzione (effettuata allo stesso modo delle due
2830 precedenti) e questa verrà restituita in una struttura \struct{timespec}
2831 all'indirizzo puntato dall'argomento \param{res}.
2833 Come accennato il valore di questa risoluzione dipende sia dall'hardware
2834 disponibile che dalla implementazione delle funzioni, e costituisce il limite
2835 minimo di un intervallo di tempo che si può indicare. Qualunque valore si
2836 voglia utilizzare nelle funzioni di impostazione che non corrisponda ad un
2837 multiplo intero di questa risoluzione, sarà troncato in maniera automatica.
2839 Si tenga presente inoltre che con l'introduzione degli \textit{high resolution
2840 timer} i due orologi \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
2841 \const{CLOCK\_THREAD\_CPUTIME\_ID} fanno riferimento ai contatori presenti in
2842 opportuni registri interni del processore; questo sui sistemi multiprocessore
2843 può avere delle ripercussioni sulla precisione delle misure di tempo che vanno
2844 al di là della risoluzione teorica ottenibile con \func{clock\_getres}, che
2845 può essere ottenuta soltanto quando si è sicuri che un processo (o un
2846 \textit{thread}) sia sempre stato eseguito sullo stesso processore.
2848 Con i sistemi multiprocessore infatti ogni singola CPU ha i suoi registri
2849 interni, e se ciascuna di esse utilizza una base di tempo diversa (se cioè il
2850 segnale di temporizzazione inviato ai processori non ha una sola provenienza)
2851 in genere ciascuna di queste potrà avere delle frequenze leggermente diverse,
2852 e si otterranno pertanto dei valori dei contatori scorrelati fra loro, senza
2853 nessuna possibilità di sincronizzazione.
2855 Il problema si presenta, in forma più lieve, anche se la base di tempo è la
2856 stessa, dato che un sistema multiprocessore non avvia mai tutte le CPU allo
2857 stesso istante, si potrà così avere di nuovo una differenza fra i contatori,
2858 soggetta però soltanto ad uno sfasamento costante. Per questo caso il kernel
2859 per alcune architetture ha del codice che consente di ridurre al minimo la
2860 differenza, ma non può essere comunque garantito che questa si annulli (anche
2861 se in genere risulta molto piccola e trascurabile nella gran parte dei casi).
2863 Per poter gestire questo tipo di problematiche lo standard ha previsto una
2864 apposita funzione che sia in grado di ottenere l'identificativo dell'orologio
2865 associato al \textit{process time} di un processo, la funzione è
2866 \funcd{clock\_getcpuclockid} ed il suo prototipo è:
2870 \funcdecl{int clock\_getcpuclockid(pid\_t pid, clockid\_t *clockid)}
2872 Ottiene l'identificatore dell'orologio di CPU usato da un processo.
2874 \bodydesc{La funzione restituisce 0 in caso di successo o un numero positivo
2875 in caso di errore, nel qual caso \var{errno} assumerà uno dei seguenti
2878 \item[\errcode{ENOSYS}] non c'è il supporto per ottenere l'orologio relativo
2879 al \textit{process time} di un altro processo, e \param{pid} non
2880 corrisponde al processo corrente.
2881 \item[\errcode{EPERM}] il chiamante non ha il permesso di accedere alle
2882 informazioni relative al processo \param{pid}.
2883 \item[\errcode{ESRCH}] non esiste il processo \param{pid}.
2889 La funzione ritorna l'identificativo di un orologio di sistema associato ad un
2890 processo indicato tramite l'argomento \param{pid}. Un utente normale, posto
2891 che il kernel sia sufficientemente recente da supportare questa funzionalità,
2892 può accedere soltanto ai dati relativi ai propri processi.
2894 Del tutto analoga a \func{clock\_getcpuclockid}, ma da utilizzare per ottenere
2895 l'orologio associato ad un \textit{thread} invece che a un processo, è
2896 \funcd{pthread\_getcpuclockid},\footnote{per poter usare la funzione, come per
2897 qualunque funzione che faccia riferimento ai \textit{thread}, occorre
2898 effettuare il collegamento alla relativa libreria di gestione compilando il
2899 programma con \texttt{-lpthread}.} il cui prototipo è:
2901 \headdecl{pthread.h}
2904 \funcdecl{int pthread\_getcpuclockid(pthread\_t thread, clockid\_t *clockid)}
2906 Ottiene l'identificatore dell'orologio di CPU associato ad un
2909 \bodydesc{La funzione restituisce 0 in caso di successo o un numero positivo
2910 in caso di errore, nel qual caso \var{errno} assumerà uno dei seguenti
2913 \item[\errcode{ENOENT}] la funzione non è supportata dal sistema.
2914 \item[\errcode{ESRCH}] non esiste il \textit{thread} identificato
2920 % TODO, dal 2.6.39 aggiunta clock_adjtime
2921 % TODO manca clock_nanosleep
2923 Con l'introduzione degli orologi ad alta risoluzione è divenuto possibile
2924 ottenere anche una gestione più avanzata degli allarmi; abbiamo già visto in
2925 sez.~\ref{sec:sig_alarm_abort} come l'interfaccia di \func{setitimer} derivata
2926 da BSD presenti delle serie limitazioni,\footnote{in particolare la
2927 possibilità di perdere un segnale sotto carico.} tanto che nello standard
2928 POSIX.1-2008 questa viene marcata come obsoleta, e ne viene fortemente
2929 consigliata la sostituzione con nuova interfaccia definita dallo standard
2930 POSIX.1-2001 che va sotto il nome di \textit{Posix Timer API}. Questa
2931 interfaccia è stata introdotta a partire dal kernel 2.6, anche se il supporto
2932 di varie funzionalità è stato aggiunto solo in un secondo tempo.
2934 Una delle principali differenze della nuova interfaccia è che un processo può
2935 utilizzare un numero arbitrario di timer; questi vengono creati (ma non
2936 avviati) tramite la funzione \funcd{timer\_create}, il cui prototipo è:
2941 \funcdecl{int timer\_create(clockid\_t clockid, struct sigevent *evp,
2944 Crea un nuovo timer Posix.
2946 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
2947 errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
2949 \item[\errcode{EAGAIN}] fallimento nel tentativo di allocare le strutture
2951 \item[\errcode{EINVAL}] uno dei valori specificati per \param{clockid} o per
2952 i campi \var{sigev\_notify}, \var{sigev\_signo} o
2953 \var{sigev\_notify\_thread\_id} di \param{evp} non è valido.
2954 \item[\errcode{ENOMEM}] errore di allocazione della memoria.
2959 La funzione richiede tre argomenti: il primo argomento serve ad indicare quale
2960 tipo di orologio si vuole utilizzare e prende uno dei valori di
2961 tab.~\ref{tab:sig_timer_clockid_types},\footnote{di detti valori però non è
2962 previsto l'uso di \const{CLOCK\_MONOTONIC\_RAW} mentre
2963 \const{CLOCK\_PROCESS\_CPUTIME\_ID} e \const{CLOCK\_THREAD\_CPUTIME\_ID}
2964 sono disponibili solo a partire dal kernel 2.6.12.} si può così fare
2965 riferimento sia ad un tempo assoluto che al tempo utilizzato dal processo (o
2966 \textit{thread}) stesso.
2968 Il secondo argomento richiede una trattazione più dettagliata, in quanto
2969 introduce una struttura di uso generale, \struct{sigevent}, che viene
2970 utilizzata anche da altre funzioni, come quelle per l'I/O asincrono (vedi
2971 sez.~\ref{sec:file_asyncronous_io}) o le code di messaggi POSIX (vedi
2972 sez.~\ref{sec:ipc_posix_mq})) e che serve ad indicare in maniera generica un
2973 meccanismo di notifica.
2975 \begin{figure}[!htb]
2976 \footnotesize \centering
2977 \begin{minipage}[c]{\textwidth}
2978 \includestruct{listati/sigevent.h}
2981 \caption{La struttura \structd{sigevent}, usata per specificare in maniera
2982 generica diverse modalità di notifica degli eventi.}
2983 \label{fig:struct_sigevent}
2986 La struttura \struct{sigevent} (accessibile includendo \headfile{time.h}) è
2987 riportata in fig.~\ref{fig:struct_sigevent};\footnote{la definizione effettiva
2988 dipende dall'implementazione, quella mostrata è la versione descritta nella
2989 pagina di manuale di \func{timer\_create}.} il campo \var{sigev\_notify} è
2990 il più importante essendo quello che indica le modalità della notifica, gli
2991 altri dipendono dal valore che si è specificato per \var{sigev\_notify}, si
2992 sono riportati in tab.~\ref{tab:sigevent_sigev_notify}. La scelta del
2993 meccanismo di notifica viene fatta impostando uno dei valori di
2994 tab.~\ref{tab:sigevent_sigev_notify} per \var{sigev\_notify}, e fornendo gli
2995 eventuali ulteriori argomenti necessari a secondo della scelta
2996 effettuata. Diventa così possibile indicare l'uso di un segnale o l'esecuzione
2997 (nel caso di uso dei \textit{thread}) di una funzione di modifica in un
2998 \textit{thread} dedicato.
3003 \begin{tabular}[c]{|l|p{10cm}|}
3005 \textbf{Valore} & \textbf{Significato} \\
3008 \const{SIGEV\_NONE} & Non viene inviata nessuna notifica.\\
3009 \const{SIGEV\_SIGNAL} & La notifica viene effettuata inviando al processo
3010 chiamante il segnale specificato dal campo
3011 \var{sigev\_signo}; se il gestore di questo
3012 segnale è stato installato con
3013 \const{SA\_SIGINFO} gli verrà restituito il
3014 valore specificato con \var{sigev\_value} (una
3015 \direct{union} \texttt{sigval}, la cui definizione
3016 è in fig.~\ref{fig:sig_sigval}) come valore del
3017 campo \var{si\_value} di \struct{siginfo\_t}.\\
3018 \const{SIGEV\_THREAD} & La notifica viene effettuata creando un nuovo
3019 \itindex{thread} \textit{thread} che esegue la
3020 funzione di notifica specificata da
3021 \var{sigev\_notify\_function} con argomento
3022 \var{sigev\_value}. Se questo è diverso da
3023 \val{NULL}, il \textit{thread} viene creato con
3024 gli attributi specificati da
3025 \var{sigev\_notify\_attribute}.\footnotemark\\
3026 \const{SIGEV\_THREAD\_ID}& Invia la notifica come segnale (con le stesse
3027 modalità di \const{SIGEV\_SIGNAL}) che però viene
3028 recapitato al \textit{thread} indicato dal campo
3029 \var{sigev\_notify\_thread\_id}. Questa modalità
3030 è una estensione specifica di Linux, creata come
3031 supporto per le librerie di gestione dei
3032 \textit{thread}, pertanto non deve essere usata
3033 da codice normale.\\
3036 \caption{Valori possibili per il campo \var{sigev\_notify} in una struttura
3038 \label{tab:sigevent_sigev_notify}
3041 \footnotetext{nel caso dei \textit{timer} questa funzionalità è considerata un
3042 esempio di pessima implementazione di una interfaccia, richiesta dallo
3043 standard POSIX, ma da evitare totalmente, a causa della possibilità di
3044 creare disservizi generando una gran quantità di processi, tanto che ne è
3045 stata richiesta addirittura la rimozione.}
3047 Nel caso di \func{timer\_create} occorrerà passare alla funzione come secondo
3048 argomento l'indirizzo di una di queste strutture per indicare le modalità con
3049 cui si vuole essere notificati della scadenza del timer, se non si specifica
3050 nulla (passando un valore \val{NULL}) verrà inviato il segnale
3051 \signal{SIGALRM} al processo corrente, o per essere più precisi verrà
3052 utilizzato un valore equivalente all'aver specificato \const{SIGEV\_SIGNAL}
3053 per \var{sigev\_notify}, \signal{SIGALRM} per \var{sigev\_signo} e
3054 l'identificatore del timer come valore per \var{sigev\_value.sival\_int}.
3056 Il terzo argomento deve essere l'indirizzo di una variabile di tipo
3057 \type{timer\_t} dove sarà scritto l'identificativo associato al timer appena
3058 creato, da usare in tutte le successive funzioni di gestione. Una volta creato
3059 questo identificativo resterà univoco all'interno del processo stesso fintanto
3060 che il timer non viene cancellato.
3062 Si tenga presente che eventuali POSIX timer creati da un processo non vengono
3063 ereditati dai processi figli creati con \func{fork} e che vengono cancellati
3064 nella esecuzione di un programma diverso attraverso una delle funzioni
3065 \func{exec}. Si tenga presente inoltre che il kernel prealloca l'uso di un
3066 segnale \textit{real-time} per ciascun timer che viene creato con
3067 \func{timer\_create}; dato che ciascuno di essi richiede un posto nella coda
3068 dei segnali \textit{real-time}, il numero massimo di timer utilizzabili da un
3069 processo è limitato dalle dimensioni di detta coda, ed anche, qualora questo
3070 sia stato impostato, dal limite \const{RLIMIT\_SIGPENDING}.
3072 Una volta creato il timer \func{timer\_create} ed ottenuto il relativo
3073 identificatore, si può attivare o disattivare un allarme (in gergo
3074 \textsl{armare} o \textsl{disarmare} il timer) con la funzione
3075 \funcd{timer\_settime}, il cui prototipo è:
3080 \funcdecl{int timer\_settime(timer\_t timerid, int flags, const struct
3081 itimerspec *new\_value, struct itimerspec *old\_value)}
3083 Arma o disarma il timer POSIX.
3085 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
3086 errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
3088 \item[\errcode{EINVAL}] all'interno di \param{new\_value.value} si è
3089 specificato un tempo negativo o un numero di nanosecondi maggiore di
3091 \item[\errcode{EFAULT}] si è specificato un indirizzo non valido
3092 per \param{new\_value} o \param{old\_value}.
3097 La funzione richiede che si indichi la scadenza del timer con
3098 l'argomento \param{new\_value}, che deve essere specificato come puntatore ad
3099 una struttura di tipo \struct{itimerspec}, la cui definizione è riportata in
3100 fig.~\ref{fig:struct_itimerspec}; se il puntatore \param{old\_value} è diverso
3101 da \val{NULL} il valore corrente della scadenza verrà restituito in una
3102 analoga struttura, ovviamente in entrambi i casi le strutture devono essere
3105 \begin{figure}[!htb]
3106 \footnotesize \centering
3107 \begin{minipage}[c]{\textwidth}
3108 \includestruct{listati/itimerspec.h}
3111 \caption{La struttura \structd{itimerspec}, usata per specificare la
3112 scadenza di un allarme.}
3113 \label{fig:struct_itimerspec}
3116 Ciascuno dei due campi di \struct{itimerspec} indica un tempo, da specificare
3117 con una precisione fino al nanosecondo tramite una struttura \struct{timespec}
3118 (la cui definizione è riportata fig.~\ref{fig:sys_timespec_struct}). Il campo
3119 \var{it\_value} indica la prima scadenza dell'allarme. Di default, quando il
3120 valore di \param{flags} è nullo, questo valore viene considerato come un
3121 intervallo relativo al tempo corrente, il primo allarme scatterà cioè dopo il
3122 numero di secondi e nanosecondi indicati da questo campo. Se invece si usa
3123 per \param{flags} il valore \const{TIMER\_ABSTIME}, che al momento è l'unico
3124 valore valido per \param{flags}, allora \var{it\_value} viene considerato come
3125 un valore assoluto rispetto al valore usato dall'orologio a cui è associato il
3126 timer.\footnote{quindi a seconda dei casi lo si potrà indicare o come un tempo
3127 assoluto, quando si opera rispetto all'orologio di sistema (nel qual caso il
3128 valore deve essere in secondi e nanosecondi dalla \textit{epoch}) o come
3129 numero di secondi o nanosecondi rispetto alla partenza di un orologio di
3130 CPU, quando si opera su uno di questi.} Infine un valore nullo di
3131 \var{it\_value}, dover per nullo si intende con valori nulli per entrambi i
3132 campi \var{tv\_sec} e \var{tv\_nsec}, può essere utilizzato, indipendentemente
3133 dal tipo di orologio utilizzato, per disarmare l'allarme.
3135 Il campo \var{it\_interval} di \struct{itimerspec} viene invece utilizzato per
3136 impostare un allarme periodico. Se il suo valore è nullo, se cioè sono nulli
3137 tutti e due i due campi \var{tv\_sec} e \var{tv\_nsec} di detta struttura
3138 \struct{timespec}, l'allarme scatterà una sola volta secondo quando indicato
3139 con \var{it\_value}, altrimenti il valore specificato nella struttura verrà
3140 preso come l'estensione del periodo di ripetizione della generazione
3141 dell'allarme, che proseguirà indefinitamente fintanto che non si disarmi il
3144 Se il timer era già stato armato la funzione sovrascrive la precedente
3145 impostazione, se invece si indica come prima scadenza un tempo già passato,
3146 l'allarme verrà notificato immediatamente e al contempo verrà incrementato il
3147 contatore dei superamenti. Questo contatore serve a fornire una indicazione al
3148 programma che riceve l'allarme su un eventuale numero di scadenze che sono
3149 passate prima della ricezione della notifica dell'allarme.
3151 É infatti possibile, qualunque sia il meccanismo di notifica scelto, che
3152 quest'ultima venga ricevuta dopo che il timer è scaduto più di una
3153 volta.\footnote{specialmente se si imposta un timer con una ripetizione a
3154 frequenza elevata.} Nel caso dell'uso di un segnale infatti il sistema mette
3155 in coda un solo segnale per timer,\footnote{questo indipendentemente che si
3156 tratti di un segnale ordinario o \textit{real-time}; per questi ultimi
3157 sarebbe anche possibile inviare un segnale per ogni scadenza, questo però
3158 non viene fatto per evitare il rischio, tutt'altro che remoto, di riempire
3159 la coda.} e se il sistema è sotto carico o se il segnale è bloccato, prima
3160 della sua ricezione può passare un intervallo di tempo sufficientemente lungo
3161 ad avere scadenze multiple, e lo stesso può accadere anche se si usa un
3162 \textit{thread} di notifica.
3164 Per questo motivo il gestore del segnale o il \textit{thread} di notifica può
3165 ottenere una indicazione di quante volte il timer è scaduto dall'invio della
3166 notifica utilizzando la funzione \funcd{timer\_getoverrun}, il cui prototipo è:
3170 \funcdecl{int timer\_getoverrun(timer\_t timerid)}
3172 Ottiene il numero di scadenze di un timer POSIX.
3174 \bodydesc{La funzione restituisce il numero di scadenze di un timer in caso
3175 di successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà
3178 \item[\errcode{EINVAL}] \param{timerid} non indica un timer valido.
3183 La funzione ritorna il numero delle scadenze avvenute, che può anche essere
3184 nullo se non ve ne sono state. Come estensione specifica di Linux,\footnote{in
3185 realtà lo standard POSIX.1-2001 prevede gli \textit{overrun} solo per i
3186 segnali e non ne parla affatto in riferimento ai \textit{thread}.} quando
3187 si usa un segnale come meccanismo di notifica, si può ottenere direttamente
3188 questo valore nel campo \var{si\_overrun} della struttura \struct{siginfo\_t}
3189 (illustrata in fig.~\ref{fig:sig_siginfo_t}) restituita al gestore del segnale
3190 installato con \func{sigaction}; in questo modo non è più necessario eseguire
3191 successivamente una chiamata a questa funzione per ottenere il numero delle
3192 scadenze. Al gestore del segnale viene anche restituito, come ulteriore
3193 informazione, l'identificativo del timer, in questo caso nel campo
3196 Qualora si voglia rileggere lo stato corrente di un timer, ed ottenere il
3197 tempo mancante ad una sua eventuale scadenza, si deve utilizzare la funzione
3198 \funcd{timer\_gettime}, il cui prototipo è:
3202 \funcdecl{int timer\_gettime(timer\_t timerid, int flags, struct
3203 itimerspec *curr\_value)}
3205 Legge lo stato di un timer POSIX.
3207 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
3208 errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
3210 \item[\errcode{EINVAL}] \param{timerid} non indica un timer valido.
3211 \item[\errcode{EFAULT}] si è specificato un indirizzo non valido
3212 per \param{curr\_value}.
3217 La funzione restituisce nella struttura \struct{itimerspec} puntata
3218 da \param{curr\_value} il tempo restante alla prossima scadenza nel campo
3219 \var{it\_value}. Questo tempo viene sempre indicato in forma relativa, anche
3220 nei casi in cui il timer era stato precedentemente impostato con
3221 \const{TIMER\_ABSTIME} indicando un tempo assoluto. Il ritorno di un valore
3222 nullo nel campo \var{it\_value} significa che il timer è disarmato o è
3223 definitivamente scaduto.
3225 Nel campo \var{it\_interval} di \param{curr\_value} viene invece restituito,
3226 se questo era stato impostato, il periodo di ripetizione del timer. Anche in
3227 questo caso il ritorno di un valore nullo significa che il timer non era stato
3228 impostato per una ripetizione e doveva operare, come suol dirsi, a colpo
3229 singolo (in gergo \textit{one shot}).
3231 Infine, quando un timer non viene più utilizzato, lo si può cancellare,
3232 rimuovendolo dal sistema e recuperando le relative risorse, effettuando in
3233 sostanza l'operazione inversa rispetto a \funcd{timer\_create}. Per questo
3234 compito lo standard prevede una apposita funzione \funcd{timer\_delete}, il
3239 \funcdecl{int timer\_delete(timer\_t timerid)}
3241 Cancella un timer POSIX.
3243 \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
3244 errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
3246 \item[\errcode{EINVAL}] \param{timerid} non indica un timer valido.
3251 La funzione elimina il timer identificato da \param{timerid}, disarmandolo se
3252 questo era stato attivato. Nel caso, poco probabile ma comunque possibile, che
3253 un timer venga cancellato prima della ricezione del segnale pendente per la
3254 notifica di una scadenza, il comportamento del sistema è indefinito.
3256 \subsection{Ulteriori funzioni di gestione}
3257 \label{sec:sig_specific_features}
3259 In questo ultimo paragrafo esamineremo le rimanenti funzioni di gestione dei
3260 segnali non descritte finora, relative agli aspetti meno utilizzati e più
3261 ``\textsl{esoterici}'' della interfaccia.
3263 La prima di queste funzioni è \funcd{sigpending}, anch'essa introdotta dallo
3264 standard POSIX.1; il suo prototipo è:
3265 \begin{prototype}{signal.h}
3266 {int sigpending(sigset\_t *set)}
3268 Scrive in \param{set} l'insieme dei segnali pendenti.
3270 \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
3274 La funzione permette di ricavare quali sono i segnali pendenti per il processo
3275 in corso, cioè i segnali che sono stati inviati dal kernel ma non sono stati
3276 ancora ricevuti dal processo in quanto bloccati. Non esiste una funzione
3277 equivalente nella vecchia interfaccia, ma essa è tutto sommato poco utile,
3278 dato che essa può solo assicurare che un segnale è stato inviato, dato che
3279 escluderne l'avvenuto invio al momento della chiamata non significa nulla
3280 rispetto a quanto potrebbe essere in un qualunque momento successivo.
3282 Una delle caratteristiche di BSD, disponibile anche in Linux, è la possibilità
3283 di usare uno \itindex{stack} \textit{stack} alternativo per i segnali; è cioè
3284 possibile fare usare al sistema un altro \itindex{stack} \textit{stack}
3285 (invece di quello relativo al processo, vedi sez.~\ref{sec:proc_mem_layout})
3286 solo durante l'esecuzione di un gestore. L'uso di uno \textit{stack}
3287 alternativo è del tutto trasparente ai gestori, occorre però seguire una certa
3290 \item allocare un'area di memoria di dimensione sufficiente da usare come
3291 \textit{stack} alternativo;
3292 \item usare la funzione \func{sigaltstack} per rendere noto al sistema
3293 l'esistenza e la locazione dello \textit{stack} alternativo;
3294 \item quando si installa un gestore occorre usare \func{sigaction}
3295 specificando il flag \const{SA\_ONSTACK} (vedi tab.~\ref{tab:sig_sa_flag})
3296 per dire al sistema di usare lo \textit{stack} alternativo durante
3297 l'esecuzione del gestore.
3300 In genere il primo passo viene effettuato allocando un'opportuna area di
3301 memoria con \code{malloc}; in \headfile{signal.h} sono definite due costanti,
3302 \const{SIGSTKSZ} e \const{MINSIGSTKSZ}, che possono essere utilizzate per
3303 allocare una quantità di spazio opportuna, in modo da evitare overflow. La
3304 prima delle due è la dimensione canonica per uno \itindex{stack}
3305 \textit{stack} di segnali e di norma è sufficiente per tutti gli usi normali.
3307 La seconda è lo spazio che occorre al sistema per essere in grado di lanciare
3308 il gestore e la dimensione di uno \textit{stack} alternativo deve essere
3309 sempre maggiore di questo valore. Quando si conosce esattamente quanto è lo
3310 spazio necessario al gestore gli si può aggiungere questo valore per allocare
3311 uno \itindex{stack} \textit{stack} di dimensione sufficiente.
3313 Come accennato, per poter essere usato, lo \itindex{stack} \textit{stack} per
3314 i segnali deve essere indicato al sistema attraverso la funzione
3315 \funcd{sigaltstack}; il suo prototipo è:
3316 \begin{prototype}{signal.h}
3317 {int sigaltstack(const stack\_t *ss, stack\_t *oss)}
3319 Installa un nuovo \textit{stack} per i segnali.
3321 \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
3322 errore, nel qual caso \var{errno} assumerà i valori:
3325 \item[\errcode{ENOMEM}] la dimensione specificata per il nuovo
3326 \textit{stack} è minore di \const{MINSIGSTKSZ}.
3327 \item[\errcode{EPERM}] uno degli indirizzi non è valido.
3328 \item[\errcode{EFAULT}] si è cercato di cambiare lo \textit{stack}
3329 alternativo mentre questo è attivo (cioè il processo è in esecuzione su di
3331 \item[\errcode{EINVAL}] \param{ss} non è nullo e \var{ss\_flags} contiene un
3332 valore diverso da zero che non è \const{SS\_DISABLE}.
3336 La funzione prende come argomenti puntatori ad una struttura di tipo
3337 \var{stack\_t}, definita in fig.~\ref{fig:sig_stack_t}. I due valori
3338 \param{ss} e \param{oss}, se non nulli, indicano rispettivamente il nuovo
3339 \itindex{stack} \textit{stack} da installare e quello corrente (che viene
3340 restituito dalla funzione per un successivo ripristino).
3342 \begin{figure}[!htb]
3343 \footnotesize \centering
3344 \begin{minipage}[c]{\textwidth}
3345 \includestruct{listati/stack_t.h}
3348 \caption{La struttura \structd{stack\_t}.}
3349 \label{fig:sig_stack_t}
3352 Il campo \var{ss\_sp} di \struct{stack\_t} indica l'indirizzo base dello
3353 \itindex{stack} \textit{stack}, mentre \var{ss\_size} ne indica la dimensione;
3354 il campo \var{ss\_flags} invece indica lo stato dello \textit{stack}.
3355 Nell'indicare un nuovo \textit{stack} occorre inizializzare \var{ss\_sp} e
3356 \var{ss\_size} rispettivamente al puntatore e alla dimensione della memoria
3357 allocata, mentre \var{ss\_flags} deve essere nullo. Se invece si vuole
3358 disabilitare uno \textit{stack} occorre indicare \const{SS\_DISABLE} come
3359 valore di \var{ss\_flags} e gli altri valori saranno ignorati.
3361 Se \param{oss} non è nullo verrà restituito dalla funzione indirizzo e
3362 dimensione dello \itindex{stack} \textit{stack} corrente nei relativi campi,
3363 mentre \var{ss\_flags} potrà assumere il valore \const{SS\_ONSTACK} se il
3364 processo è in esecuzione sullo \textit{stack} alternativo (nel qual caso non è
3365 possibile cambiarlo) e \const{SS\_DISABLE} se questo non è abilitato.
3367 In genere si installa uno \itindex{stack} \textit{stack} alternativo per i
3368 segnali quando si teme di avere problemi di esaurimento dello \textit{stack}
3369 standard o di superamento di un limite (vedi
3370 sez.~\ref{sec:sys_resource_limit}) imposto con chiamate del tipo
3371 \code{setrlimit(RLIMIT\_STACK, \&rlim)}. In tal caso infatti si avrebbe un
3372 segnale di \signal{SIGSEGV}, che potrebbe essere gestito soltanto avendo
3373 abilitato uno \itindex{stack} \textit{stack} alternativo.
3375 Si tenga presente che le funzioni chiamate durante l'esecuzione sullo
3376 \textit{stack} alternativo continueranno ad usare quest'ultimo, che, al
3377 contrario di quanto avviene per lo \itindex{stack} \textit{stack} ordinario
3378 dei processi, non si accresce automaticamente (ed infatti eccederne le
3379 dimensioni può portare a conseguenze imprevedibili). Si ricordi infine che
3380 una chiamata ad una funzione della famiglia \func{exec} cancella ogni
3381 \textit{stack} alternativo.
3383 Abbiamo visto in fig.~\ref{fig:sig_sleep_incomplete} come si possa usare
3384 \func{longjmp} per uscire da un gestore rientrando direttamente nel corpo
3385 del programma; sappiamo però che nell'esecuzione di un gestore il segnale
3386 che l'ha invocato viene bloccato, e abbiamo detto che possiamo ulteriormente
3387 modificarlo con \func{sigprocmask}.
3389 Resta quindi il problema di cosa succede alla maschera dei segnali quando si
3390 esce da un gestore usando questa funzione. Il comportamento dipende
3391 dall'implementazione; in particolare la semantica usata da BSD prevede che sia
3392 ripristinata la maschera dei segnali precedente l'invocazione, come per un
3393 normale ritorno, mentre quella usata da System V no.
3395 Lo standard POSIX.1 non specifica questo comportamento per \func{setjmp} e
3396 \func{longjmp}, ed il comportamento delle \acr{glibc} dipende da quale delle
3397 caratteristiche si sono abilitate con le macro viste in
3398 sez.~\ref{sec:intro_gcc_glibc_std}.
3400 Lo standard POSIX però prevede anche la presenza di altre due funzioni
3401 \funcd{sigsetjmp} e \funcd{siglongjmp}, che permettono di decidere quale dei
3402 due comportamenti il programma deve assumere; i loro prototipi sono:
3406 \funcdecl{int sigsetjmp(sigjmp\_buf env, int savesigs)} Salva il contesto
3407 dello \textit{stack} per un \index{salto~non-locale} salto non-locale.
3409 \funcdecl{void siglongjmp(sigjmp\_buf env, int val)} Esegue un salto
3410 non-locale su un precedente contesto.
3412 \bodydesc{Le due funzioni sono identiche alle analoghe \func{setjmp} e
3413 \func{longjmp} di sez.~\ref{sec:proc_longjmp}, ma consentono di specificare
3414 il comportamento sul ripristino o meno della maschera dei segnali.}
3417 Le due funzioni prendono come primo argomento la variabile su cui viene
3418 salvato il contesto dello \itindex{stack} \textit{stack} per permettere il
3419 \index{salto~non-locale} salto non-locale; nel caso specifico essa è di tipo
3420 \type{sigjmp\_buf}, e non \type{jmp\_buf} come per le analoghe di
3421 sez.~\ref{sec:proc_longjmp} in quanto in questo caso viene salvata anche la
3422 maschera dei segnali.
3424 Nel caso di \func{sigsetjmp}, se si specifica un valore di \param{savesigs}
3425 diverso da zero la maschera dei valori sarà salvata in \param{env} e
3426 ripristinata in un successivo \func{siglongjmp}; quest'ultima funzione, a
3427 parte l'uso di \type{sigjmp\_buf} per \param{env}, è assolutamente identica a
3431 % TODO: se e quando si troverà un argomento adeguato inserire altre funzioni
3432 % sparse attinenti ai segnali, al momento sono note solo:
3433 % * sigreturn (funzione interna, scarsamente interessante)
3434 % argomento a priorità IDLE (fare quando non resta niente altro da trattare)
3437 % LocalWords: kernel POSIX timer shell control ctrl kill raise signal handler
3438 % LocalWords: reliable unreliable fig race condition sez struct process table
3439 % LocalWords: delivered pending scheduler sigpending l'I suspend SIGKILL wait
3440 % LocalWords: SIGSTOP sigaction waitpid dump stack debugger nell'header NSIG
3441 % LocalWords: tab BSD SUSv SIGHUP PL Hangup SIGINT Interrupt SIGQUIT Quit AEF
3442 % LocalWords: SIGILL SIGABRT abort SIGFPE SIGSEGV SIGPIPE SIGALRM alarm SIGUSR
3443 % LocalWords: SIGTERM SIGCHLD SIGCONT SIGTSTP SIGTTIN SIGTTOU SIGBUS bad SL of
3444 % LocalWords: memory access SIGPOLL Pollable event Sys SIGIO SIGPROF profiling
3445 % LocalWords: SIGSYS SVID SIGTRAP breakpoint SIGURG urgent socket Virtual IOT
3446 % LocalWords: clock SIGXCPU SIGXFSZ SIGIOT trap SIGEMT SIGSTKFLT SIGCLD SIGPWR
3447 % LocalWords: SIGINFO SIGLOST lock NFS SIGWINCH Sun SIGUNUSED fault point heap
3448 % LocalWords: exception l'overflow illegal instruction overflow segment error
3449 % LocalWords: violation system call interrupt INTR hang SIGVTALRM virtual SUSP
3450 % LocalWords: profilazione fcntl descriptor sleep interactive Broken FIFO lost
3451 % LocalWords: EPIPE Resource advisory client limit exceeded size window change
3452 % LocalWords: strsignal psignal SOURCE strerror string char int signum perror
3453 % LocalWords: void sig const sys siglist L'array decr fork exec DFL IGN ioctl
3454 % LocalWords: EINTR glibc TEMP FAILURE RETRY expr multitasking SVr sighandler
3455 % LocalWords: ERR libc bsd sysv XOPEN EINVAL pid errno ESRCH EPERM getpid init
3456 % LocalWords: killpg pidgrp group unistd unsigned seconds all' setitimer which
3457 % LocalWords: itimerval value ovalue EFAULT ITIMER it interval timeval ms VIRT
3458 % LocalWords: getitimer stdlib stream atexit exit usleep long usec nanosleep
3459 % LocalWords: timespec req rem HZ scheduling SCHED RR SigHand forktest WNOHANG
3460 % LocalWords: deadlock longjmp setjmp sigset sigemptyset sigfillset sigaddset
3461 % LocalWords: sigdelset sigismember act oldact restorer mask NOCLDSTOP ONESHOT
3462 % LocalWords: RESETHAND RESTART NOMASK NODEFER ONSTACK sigcontext union signo
3463 % LocalWords: siginfo bits uid addr fd inline like blocked atomic sigprocmask
3464 % LocalWords: how oldset BLOCK UNBLOCK SETMASK sigsuspend sigaltstack malloc
3465 % LocalWords: SIGSTKSZ MINSIGSTKSZ ss oss ENOMEM flags DISABLE sp setrlimit LB
3466 % LocalWords: RLIMIT rlim sigsetjmp siglongjmp sigjmp buf env savesigs jmp ptr
3467 % LocalWords: SIGRTMIN SIGRTMAX sigval sigevent sigqueue EAGAIN sysctl safe tp
3468 % LocalWords: QUEUE thread sigwait sigwaitinfo sigtimedwait info DEF SLB bind
3469 % LocalWords: function accept return cfgetispeed cfgetospeed cfsetispeed chdir
3470 % LocalWords: cfsetospeed chmod chown gettime close connect creat dup execle
3471 % LocalWords: execve fchmod fchown fdatasync fpathconf fstat fsync ftruncate
3472 % LocalWords: getegid geteuid getgid getgroups getpeername getpgrp getppid sem
3473 % LocalWords: getsockname getsockopt getuid listen lseek lstat mkdir mkfifo tv
3474 % LocalWords: pathconf poll posix pselect read readlink recv recvfrom recvmsg
3475 % LocalWords: rename rmdir select send sendmsg sendto setgid setpgid setsid
3476 % LocalWords: setsockopt setuid shutdown sigpause socketpair stat symlink page
3477 % LocalWords: sysconf tcdrain tcflow tcflush tcgetattr tcgetgrp tcsendbreak
3478 % LocalWords: tcsetattr tcsetpgrp getoverrun times umask uname unlink utime
3479 % LocalWords: write sival SIVGTALRM NOCLDWAIT MESGQ ASYNCIO TKILL tkill tgkill
3480 % LocalWords: ILL ILLOPC ILLOPN ILLADR ILLTRP PRVOPC PRVREG COPROC BADSTK FPE
3481 % LocalWords: INTDIV INTOVF FLTDIV FLTOVF FLTUND underflow FLTRES FLTINV SEGV
3482 % LocalWords: FLTSUB MAPERR ACCERR ADRALN ADRERR OBJERR BRKPT CLD EXITED MSG
3483 % LocalWords: KILLED DUMPED TRAPPED STOPPED CONTINUED PRI HUP SigFunc jiffies
3484 % LocalWords: SEC unsafe sockatmark execl execv faccessat fchmodat fchownat
3485 % LocalWords: fexecve fstatat futimens linkat mkdirat mkfifoat mknod mknodat
3486 % LocalWords: openat readlinkat renameat symlinkat unlinkat utimensat utimes
3487 % LocalWords: LinuxThread NTPL Library clockid evp timerid sigev notify high
3488 % LocalWords: resolution CONFIG RES patch REALTIME MONOTONIC RAW NTP CPUTIME
3489 % LocalWords: tick calendar The Epoch list getcpuclockid capability CAP getres
3490 % LocalWords: ENOSYS pthread ENOENT NULL attribute itimerspec new old ABSTIME
3491 % LocalWords: epoch multiplexing overrun res lpthread sec nsec curr one shot
3492 % LocalWords: delete
3495 %%% Local Variables:
3497 %%% TeX-master: "gapil"