+Il valore della struttura specificata \param{value} viene usato per impostare
+il timer, se il puntatore \param{ovalue} non è nullo il precedente valore
+viene salvato qui. I valori dei timer devono essere indicati attraverso una
+struttura \struct{itimerval}, definita in \figref{fig:file_stat_struct}.
+
+La struttura è composta da due membri, il primo, \var{it\_interval} definisce
+il periodo del timer; il secondo, \var{it\_value} il tempo mancante alla
+scadenza. Entrambi esprimono i tempi tramite una struttura \struct{timeval} che
+permette una precisione fino al microsecondo.
+
+Ciascun timer decrementa il valore di \var{it\_value} fino a zero, poi invia
+il segnale e reimposta \var{it\_value} al valore di \var{it\_interval}, in
+questo modo il ciclo verrà ripetuto; se invece il valore di \var{it\_interval}
+è nullo il timer si ferma.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includestruct{listati/itimerval.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{itimerval}, che definisce i valori dei timer
+ di sistema.}
+ \label{fig:sig_itimerval}
+\end{figure}
+
+L'uso di \func{setitimer} consente dunque un controllo completo di tutte le
+caratteristiche dei timer, ed in effetti la stessa \func{alarm}, benché
+definita direttamente nello standard POSIX.1, può a sua volta essere espressa
+in termini di \func{setitimer}, come evidenziato dal manuale delle \acr{glibc}
+\cite{glibc} che ne riporta la definizione mostrata in
+\figref{fig:sig_alarm_def}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includestruct{listati/alarm_def.c}
+ \end{minipage}
+ \normalsize
+ \caption{Definizione di \func{alarm} in termini di \func{setitimer}.}
+ \label{fig:sig_alarm_def}
+\end{figure}
+
+Si deve comunque tenere presente che la precisione di queste funzioni è
+limitata da quella della frequenza del timer di sistema (che nel caso dei PC
+significa circa 10~ms). Il sistema assicura comunque che il segnale non sarà
+mai generato prima della scadenza programmata (l'arrotondamento cioè è sempre
+effettuato per eccesso).
+
+Una seconda causa di potenziali ritardi è che il segnale viene generato alla
+scadenza del timer, ma poi deve essere consegnato al processo; se quest'ultimo
+è attivo (questo è sempre vero per \const{ITIMER\_VIRT}) la consegna è
+immediata, altrimenti può esserci un ulteriore ritardo che può variare a
+seconda del carico del sistema.
+
+Questo ha una conseguenza che può indurre ad errori molto subdoli, si tenga
+conto poi che in caso di sistema molto carico, si può avere il caso patologico
+in cui un timer scade prima che il segnale di una precedente scadenza sia
+stato consegnato; in questo caso, per il comportamento dei segnali descritto
+in \secref{sec:sig_sigchld}, un solo segnale sarà consegnato.
+
+
+Dato che sia \func{alarm} che \func{setitimer} non consentono di leggere il
+valore corrente di un timer senza modificarlo, è possibile usare la funzione
+\funcd{getitimer}, il cui prototipo è:
+\begin{prototype}{sys/time.h}{int getitimer(int which, struct
+ itimerval *value)}
+
+ Legge in \param{value} il valore del timer specificato da \func{which}.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ errore e restituisce gli stessi errori di \func{getitimer}}
+\end{prototype}
+\noindent i cui parametri hanno lo stesso significato e formato di quelli di
+\func{setitimer}.
+
+
+L'ultima funzione che permette l'invio diretto di un segnale è \funcd{abort};
+che, come accennato in \secref{sec:proc_termination}, permette di abortire
+l'esecuzione di un programma tramite l'invio di \const{SIGABRT}. Il suo
+prototipo è:
+\begin{prototype}{stdlib.h}{void abort(void)}
+
+ Abortisce il processo corrente.
+
+ \bodydesc{La funzione non ritorna, il processo è terminato inviando il
+ segnale di \const{SIGABRT}.}
+\end{prototype}
+
+La differenza fra questa funzione e l'uso di \func{raise} è che anche se il
+segnale è bloccato o ignorato, la funzione ha effetto lo stesso. Il segnale
+può però essere intercettato per effettuare eventuali operazioni di chiusura
+prima della terminazione del processo.
+
+Lo standard ANSI C richiede inoltre che anche se il gestore ritorna, la
+funzione non ritorni comunque. Lo standard POSIX.1 va oltre e richiede che se
+il processo non viene terminato direttamente dal gestore sia la stessa
+\func{abort} a farlo al ritorno dello stesso. Inoltre, sempre seguendo lo
+standard POSIX, prima della terminazione tutti i file aperti e gli stream
+saranno chiusi ed i buffer scaricati su disco. Non verranno invece eseguite le
+eventuali funzioni registrate con \func{at\_exit} e \func{on\_exit}.
+
+
+\subsection{Le funzioni di pausa e attesa}
+\label{sec:sig_pause_sleep}
+
+Sono parecchie le occasioni in cui si può avere necessità di sospendere
+temporaneamente l'esecuzione di un processo. Nei sistemi più elementari in
+genere questo veniva fatto con un opportuno loop di attesa, ma in un sistema
+multitasking un loop di attesa è solo un inutile spreco di CPU, per questo ci
+sono apposite funzioni che permettono di mettere un processo in stato di
+attesa.\footnote{si tratta in sostanza di funzioni che permettono di portare
+ esplicitamente il processo in stato di \textit{sleep}, vedi
+ \secref{sec:proc_sched}.}
+
+Il metodo tradizionale per fare attendere ad un processo fino all'arrivo di un
+segnale è quello di usare la funzione \funcd{pause}, il cui prototipo è:
+\begin{prototype}{unistd.h}{int pause(void)}
+
+ Pone il processo in stato di sleep fino al ritorno di un gestore.
+
+ \bodydesc{La funzione ritorna solo dopo che un segnale è stato ricevuto ed
+ il relativo gestore è ritornato, nel qual caso restituisce -1 e
+ \var{errno} assumerà il valore \errval{EINTR}.}
+\end{prototype}
+
+La funzione segnala sempre una condizione di errore (il successo sarebbe
+quello di aspettare indefinitamente). In genere si usa questa funzione quando
+si vuole mettere un processo in attesa di un qualche evento specifico che non
+è sotto il suo diretto controllo (ad esempio la si può usare per interrompere
+l'esecuzione del processo fino all'arrivo di un segnale inviato da un altro
+processo).
+
+Quando invece si vuole fare attendere un processo per un intervallo di tempo
+già noto nello standard POSIX.1 viene definita la funzione \funcd{sleep}, il
+cui prototipo è:
+\begin{prototype}{unistd.h}{unsigned int sleep(unsigned int seconds)}
+
+ Pone il processo in stato di sleep per \param{seconds} secondi.
+
+ \bodydesc{La funzione restituisce zero se l'attesa viene completata, o il
+ numero di secondi restanti se viene interrotta da un segnale.}
+\end{prototype}
+
+La funzione attende per il tempo specificato, a meno di non essere interrotta
+da un segnale. In questo caso non è una buona idea ripetere la chiamata per il
+tempo rimanente, in quanto la riattivazione del processo può avvenire in un
+qualunque momento, ma il valore restituito sarà sempre arrotondato al secondo,
+con la conseguenza che, se la successione dei segnali è particolarmente
+sfortunata e le differenze si accumulano, si potranno avere ritardi anche di
+parecchi secondi. In genere la scelta più sicura è quella di stabilire un
+termine per l'attesa, e ricalcolare tutte le volte il numero di secondi da
+aspettare.
+
+In alcune implementazioni inoltre l'uso di \func{sleep} può avere conflitti
+con quello di \const{SIGALRM}, dato che la funzione può essere realizzata con
+l'uso di \func{pause} e \func{alarm} (in maniera analoga all'esempio che
+vedremo in \secref{sec:sig_example}). In tal caso mescolare chiamata di
+\func{alarm} e \func{sleep} o modificare l'azione di \const{SIGALRM}, può
+causare risultati indefiniti. Nel caso delle \acr{glibc} è stata usata una
+implementazione completamente indipendente e questi problemi non ci sono.
+
+La granularità di \func{sleep} permette di specificare attese soltanto in
+secondi, per questo sia sotto BSD4.3 che in SUSv2 è stata definita la funzione
+\funcd{usleep} (dove la \texttt{u} è intesa come sostituzione di $\mu$); i due
+standard hanno delle definizioni diverse, ma le \acr{glibc}
+seguono\footnote{secondo la pagina di manuale almeno dalla versione 2.2.2.}
+seguono quella di SUSv2 che prevede il seguente prototipo:
+\begin{prototype}{unistd.h}{int usleep(unsigned long usec)}
+
+ Pone il processo in stato di sleep per \param{usec} microsecondi.
+
+ \bodydesc{La funzione restituisce zero se l'attesa viene completata, o -1 in
+ caso di errore, nel qual caso \var{errno} assumerà il valore
+ \errval{EINTR}.}
+
+\end{prototype}
+
+Anche questa funzione, a seconda delle implementazioni, può presentare
+problemi nell'interazione con \func{alarm} e \const{SIGALRM}. È pertanto
+deprecata in favore della funzione \funcd{nanosleep}, definita dallo standard
+POSIX1.b, il cui prototipo è:
+\begin{prototype}{unistd.h}{int nanosleep(const struct timespec *req, struct
+ timespec *rem)}
+
+ Pone il processo in stato di sleep per il tempo specificato da \param{req}.
+ In caso di interruzione restituisce il tempo restante in \param{rem}.
+
+ \bodydesc{La funzione restituisce zero se l'attesa viene completata, o -1 in
+ caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] si è specificato un numero di secondi negativo o un
+ numero di nanosecondi maggiore di 999.999.999.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \end{errlist}}
+\end{prototype}
+
+Lo standard richiede che la funzione sia implementata in maniera del tutto
+indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto
+ utilizzando direttamente il timer del kernel.} e sia utilizzabile senza
+interferenze con l'uso di \const{SIGALRM}. La funzione prende come parametri
+delle strutture di tipo \struct{timespec}, la cui definizione è riportata in
+\figref{fig:sys_timeval_struct}, che permettono di specificare un tempo con
+una precisione (teorica) fino al nanosecondo.
+
+La funzione risolve anche il problema di proseguire l'attesa dopo
+l'interruzione dovuta ad un segnale; infatti in tal caso in \param{rem} viene
+restituito il tempo rimanente rispetto a quanto richiesto inizialmente, e
+basta richiamare la funzione per completare l'attesa.
+
+Chiaramente, anche se il tempo può essere specificato con risoluzioni fino al
+nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
+temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
+specificato, ma prima che il processo possa tornare ad essere eseguito
+occorrerà almeno attendere il successivo giro di scheduler\index{scheduler} e
+cioè un tempo che a seconda dei casi può arrivare fino a 1/\const{HZ}, (sempre
+che il sistema sia scarico ed il processa venga immediatamente rimesso in
+esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
+arrotondato al multiplo successivo di 1/\const{HZ}.
+
+In realtà è possibile ottenere anche pause più precise del centesimo di
+secondo usando politiche di scheduling real time come \const{SCHED\_FIFO} o
+\const{SCHED\_RR}; in tal caso infatti il meccanismo di scheduling ordinario
+viene evitato, e si raggiungono pause fino ai 2~ms con precisioni del $\mu$s.
+
+
+
+\subsection{Un esempio elementare}
+\label{sec:sig_sigchld}
+
+Un semplice esempio per illustrare il funzionamento di un gestore di segnale è
+quello della gestione di \const{SIGCHLD}. Abbiamo visto in
+\secref{sec:proc_termination} che una delle azioni eseguite dal kernel alla
+conclusione di un processo è quella di inviare questo segnale al
+padre.\footnote{in realtà in SVr4 eredita la semantica di System V, in cui il
+ segnale si chiama \const{SIGCLD} e viene trattato in maniera speciale; in
+ System V infatti se si imposta esplicitamente l'azione a \const{SIG\_IGN} il
+ segnale non viene generato ed il sistema non genera zombie\index{zombie} (lo
+ stato di terminazione viene scartato senza dover chiamare una \func{wait}).
+ L'azione predefinita è sempre quella di ignorare il segnale, ma non attiva
+ questo comportamento. Linux, come BSD e POSIX, non supporta questa semantica
+ ed usa il nome di \const{SIGCLD} come sinonimo di \const{SIGCHLD}.} In
+generale dunque, quando non interessa elaborare lo stato di uscita di un
+processo, si può completare la gestione della terminazione installando un
+gestore per \const{SIGCHLD} il cui unico compito sia quello chiamare
+\func{waitpid} per completare la procedura di terminazione in modo da evitare
+la formazione di zombie\index{zombie}.
+
+In \figref{fig:sig_sigchld_handl} è mostrato il codice contenente una
+implementazione generica di una routine di gestione per \const{SIGCHLD}, (che
+si trova nei sorgenti allegati nel file \file{SigHand.c}); se ripetiamo i test
+di \secref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione
+\cmd{-s} (che si limita ad effettuare l'installazione di questa funzione come
+gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione
+di zombie\index{zombie}.
+
+% è pertanto
+% naturale usare un esempio che ci permette di concludere la trattazione della
+% terminazione dei processi.
+% In questo caso si è tratterà di illustrare un esempio relativo ad un
+% gestore per che è previsto ritornare,
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/hand_sigchild.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice di una funzione generica di gestione per il segnale
+ \texttt{SIGCHLD}.}
+ \label{fig:sig_sigchld_handl}
+\end{figure}
+
+Il codice del gestore è di lettura immediata; come buona norma di
+programmazione (si ricordi quanto accennato \secref{sec:sys_errno}) si
+comincia (\texttt{\small 12-13}) con il salvare lo stato corrente di
+\var{errno}, in modo da poterlo ripristinare prima del ritorno del gestore
+(\texttt{\small 22-23}). In questo modo si preserva il valore della variabile
+visto dal corso di esecuzione principale del processo, che sarebbe altrimenti
+sarebbe sovrascritto dal valore restituito nella successiva chiamata di
+\func{wait}.
+
+Il compito principale del gestore è quello di ricevere lo stato di
+terminazione del processo, cosa che viene eseguita nel ciclo in
+(\texttt{\small 15-21}). Il ciclo è necessario a causa di una caratteristica
+fondamentale della gestione dei segnali: abbiamo già accennato come fra la
+generazione di un segnale e l'esecuzione del gestore possa passare un certo
+lasso di tempo e niente ci assicura che il gestore venga eseguito prima della
+generazione di ulteriori segnali dello stesso tipo. In questo caso normalmente
+i segnali segnali successivi vengono ``\textsl{fusi}'' col primo ed al
+processo ne viene recapitato soltanto uno.
+
+Questo può essere un caso comune proprio con \const{SIGCHLD}, qualora capiti
+che molti processi figli terminino in rapida successione. Esso inoltre si
+presenta tutte le volte che un segnale viene bloccato: per quanti siano i
+segnali emessi durante il periodo di blocco, una volta che quest'ultimo sarà
+rimosso sarà recapitato un solo segnale.
+
+Allora, nel caso della terminazione dei processi figli, se si chiamasse
+\func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un
+solo processo, anche se i processi terminati sono più di uno, e gli altri
+resterebbero in stato di zombie\index{zombie} per un tempo indefinito.
+
+Per questo occorre ripetere la chiamata di \func{waitpid} fino a che essa non
+ritorni un valore nullo, segno che non resta nessun processo di cui si debba
+ancora ricevere lo stato di terminazione (si veda \secref{sec:proc_wait} per
+la sintassi della funzione). Si noti anche come la funzione venga invocata con
+il parametro \const{WNOHANG} che permette di evitare il suo blocco quando
+tutti gli stati di terminazione sono stati ricevuti.
+
+
+
+\section{Gestione avanzata}
+\label{sec:sig_control}
+
+Le funzioni esaminate finora fanno riferimento ad alle modalità più elementari
+della gestione dei segnali; non si sono pertanto ancora prese in
+considerazione le tematiche più complesse, collegate alle varie race
+condition\index{race condition} che i segnali possono generare e alla natura
+asincrona degli stessi.
+
+Affronteremo queste problematiche in questa sezione, partendo da un esempio
+che le evidenzi, per poi prendere in esame le varie funzioni che permettono di
+risolvere i problemi più complessi connessi alla programmazione con i segnali,
+fino a trattare le caratteristiche generali della gestione dei medesimi nella
+casistica ordinaria.
+
+
+\subsection{Alcune problematiche aperte}
+\label{sec:sig_example}
+
+Come accennato in \secref{sec:sig_pause_sleep} è possibile implementare
+\func{sleep} a partire dall'uso di \func{pause} e \func{alarm}. A prima vista
+questo può sembrare di implementazione immediata; ad esempio una semplice
+versione di \func{sleep} potrebbe essere quella illustrata in
+\figref{fig:sig_sleep_wrong}.
+
+Dato che è nostra intenzione utilizzare \const{SIGALRM} il primo passo della
+nostra implementazione di sarà quello di installare il relativo gestore
+salvando il precedente (\texttt{\small 14-17}). Si effettuerà poi una
+chiamata ad \func{alarm} per specificare il tempo d'attesa per l'invio del
+segnale a cui segue la chiamata a \func{pause} per fermare il programma
+(\texttt{\small 17-19}) fino alla sua ricezione. Al ritorno di \func{pause},
+causato dal ritorno del gestore (\texttt{\small 1-9}), si ripristina il
+gestore originario (\texttt{\small 20-21}) restituendo l'eventuale tempo
+rimanente (\texttt{\small 22-23}) che potrà essere diverso da zero qualora
+l'interruzione di \func{pause} venisse causata da un altro segnale.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/sleep_danger.c}
+ \end{minipage}
+ \normalsize
+ \caption{Una implementazione pericolosa di \func{sleep}.}
+ \label{fig:sig_sleep_wrong}
+\end{figure}
+
+Questo codice però, a parte il non gestire il caso in cui si è avuta una
+precedente chiamata a \func{alarm} (che si è tralasciato per brevità),
+presenta una pericolosa race condition\index{race condition}. Infatti se il
+processo viene interrotto fra la chiamata di \func{alarm} e \func{pause} può
+capitare (ad esempio se il sistema è molto carico) che il tempo di attesa
+scada prima dell'esecuzione quest'ultima, cosicché essa sarebbe eseguita dopo
+l'arrivo di \const{SIGALRM}. In questo caso ci si troverebbe di fronte ad un
+deadlock\index{deadlock}, in quanto \func{pause} non verrebbe mai più
+interrotta (se non in caso di un altro segnale).
+
+Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
+SVr2) usando la funzione \func{longjmp} (vedi \secref{sec:proc_longjmp}) per
+uscire dal gestore; in questo modo, con una condizione sullo stato di
+uscita di quest'ultima, si può evitare la chiamata a \func{pause}, usando un
+codice del tipo di quello riportato in \figref{fig:sig_sleep_incomplete}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/sleep_defect.c}
+ \end{minipage}
+ \normalsize
+ \caption{Una implementazione ancora malfunzionante di \func{sleep}.}
+ \label{fig:sig_sleep_incomplete}
+\end{figure}
+
+In questo caso il gestore (\texttt{\small 18-26}) non ritorna come in
+\figref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 24}) per
+rientrare nel corpo principale del programma; dato che in questo caso il
+valore di uscita di \func{setjmp} è 1, grazie alla condizione in
+(\texttt{\small 9-12}) si evita comunque che \func{pause} sia chiamata a
+vuoto.
+
+Ma anche questa implementazione comporta dei problemi; in questo caso infatti
+non viene gestita correttamente l'interazione con gli altri segnali; se
+infatti il segnale di allarme interrompe un altro gestore, in questo caso
+l'esecuzione non riprenderà nel gestore in questione, ma nel ciclo
+principale, interrompendone inopportunamente l'esecuzione. Lo stesso tipo di
+problemi si presenterebbero se si volesse usare \func{alarm} per stabilire un
+timeout su una qualunque system call bloccante.
+
+Un secondo esempio è quello in cui si usa il segnale per notificare una
+qualche forma di evento; in genere quello che si fa in questo caso è impostare
+nel gestore un opportuno flag da controllare nel corpo principale del
+programma (con un codice del tipo di quello riportato in
+\figref{fig:sig_event_wrong}).
+
+\begin{figure}[!htb]
+ \footnotesize\centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/sig_alarm.c}
+ \end{minipage}
+ \normalsize
+ \caption{Un esempio non funzionante del codice per il controllo di un
+ evento generato da un segnale.}
+ \label{fig:sig_event_wrong}
+\end{figure}
+
+La logica è quella di far impostare al gestore (\texttt{\small 14-19}) una
+variabile globale preventivamente inizializzata nel programma principale, il
+quale potrà determinare, osservandone il contenuto, l'occorrenza o meno del
+segnale, e prendere le relative azioni conseguenti (\texttt{\small 6-11}).
+
+Questo è il tipico esempio di caso, già citato in \secref{sec:proc_race_cond},
+in cui si genera una race condition\index{race condition}; se infatti il
+segnale arriva immediatamente dopo l'esecuzione del controllo (\texttt{\small
+ 6}) ma prima della cancellazione del flag (\texttt{\small 7}), la sua
+occorrenza sarà perduta.
+
+Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono
+funzioni più sofisticate di quelle illustrate finora, che hanno origine dalla
+interfaccia semplice, ma poco sofisticata, dei primi sistemi Unix, in modo da
+consentire la gestione di tutti i possibili aspetti con cui un processo deve
+reagire alla ricezione di un segnale.
+
+
+
+\subsection{Gli \textsl{insiemi di segnali} o \textit{signal set}}
+\label{sec:sig_sigset}
+
+Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali
+originarie, nate con la semantica inaffidabile, hanno dei limiti non
+superabili; in particolare non è prevista nessuna funzione che permetta di
+gestire gestire il blocco dei segnali o di verificare lo stato dei segnali
+pendenti. Per questo motivo lo standard POSIX.1, insieme alla nuova semantica
+dei segnali ha introdotto una interfaccia di gestione completamente nuova, che
+permette di ottenete un controllo molto più dettagliato. In particolare lo
+standard ha introdotto un nuovo tipo di dato \type{sigset\_t}, che permette di
+rappresentare un \textsl{insieme di segnali} (un \textit{signal set}, come
+viene usualmente chiamato), che è il tipo di dato che viene usato per gestire
+il blocco dei segnali.
+
+In genere un \textsl{insieme di segnali} è rappresentato da un intero di
+dimensione opportuna, di solito si pari al numero di bit dell'architettura
+della macchina\footnote{nel caso dei PC questo comporta un massimo di 32
+ segnali distinti, dato che in Linux questi sono sufficienti non c'è
+ necessità di nessuna struttura più complicata.}, ciascun bit del quale è
+associato ad uno specifico segnale; in questo modo è di solito possibile
+implementare le operazioni direttamente con istruzioni elementari del
+processore; lo standard POSIX.1 definisce cinque funzioni per la manipolazione
+degli insiemi di segnali: \funcd{sigemptyset}, \funcd{sigfillset},
+\funcd{sigaddset}, \funcd{sigdelset} e \funcd{sigismember}, i cui prototipi
+sono:
+\begin{functions}
+ \headdecl{signal.h}
+
+ \funcdecl{int sigemptyset(sigset\_t *set)} Inizializza un insieme di segnali
+ vuoto (in cui non c'è nessun segnale).
+
+ \funcdecl{int sigfillset(sigset\_t *set)} Inizializza un insieme di segnali
+ pieno (in cui ci sono tutti i segnali).
+
+ \funcdecl{int sigaddset(sigset\_t *set, int signum)} Aggiunge il segnale
+ \param{signum} all'insieme di segnali \param{set}.
+
+ \funcdecl{int sigdelset(sigset\_t *set, int signum)} Toglie il segnale
+ \param{signum} dall'insieme di segnali \param{set}.
+
+ \funcdecl{int sigismember(const sigset\_t *set, int signum)} Controlla se il
+ segnale \param{signum} è nell'insieme di segnali \param{set}.
+
+ \bodydesc{Le prime quattro funzioni ritornano 0 in caso di successo, mentre
+ \func{sigismember} ritorna 1 se \param{signum} è in \param{set} e 0
+ altrimenti. In caso di errore tutte ritornano -1, con \var{errno}
+ impostata a \errval{EINVAL} (il solo errore possibile è che \param{signum}
+ non sia un segnale valido).}
+\end{functions}
+
+Dato che in generale non si può fare conto sulle caratteristiche di una
+implementazione (non è detto che si disponga di un numero di bit sufficienti
+per mettere tutti i segnali in un intero, o in \type{sigset\_t} possono essere
+immagazzinate ulteriori informazioni) tutte le operazioni devono essere
+comunque eseguite attraverso queste funzioni.
+
+In genere si usa un insieme di segnali per specificare quali segnali si vuole
+bloccare, o per riottenere dalle varie funzioni di gestione la maschera dei
+segnali attivi (vedi \secref{sec:sig_sigmask}). Essi possono essere definiti
+in due diverse maniere, aggiungendo i segnali voluti ad un insieme vuoto
+ottenuto con \func{sigemptyset} o togliendo quelli che non servono da un
+insieme completo ottenuto con \func{sigfillset}. Infine \func{sigismember}
+permette di verificare la presenza di uno specifico segnale in un
+insieme.
+
+
+\subsection{La funzione \func{sigaction}}
+\label{sec:sig_sigaction}
+
+Abbiamo già accennato in \secref{sec:sig_signal} i problemi di compatibilità
+relativi all'uso di \func{signal}. Per ovviare a tutto questo lo standard
+POSIX.1 ha ridefinito completamente l'interfaccia per la gestione dei segnali,
+rendendola molto più flessibile e robusta, anche se leggermente più complessa.
+
+La funzione principale dell'interfaccia POSIX.1 per i segnali è
+\funcd{sigaction}. Essa ha sostanzialemente lo stesso uso di \func{signal},
+permette cioè di specificare le modalità con cui un segnale può essere gestito
+da un processo. Il suo prototipo è:
+\begin{prototype}{signal.h}{int sigaction(int signum, const struct sigaction
+ *act, struct sigaction *oldact)}
+
+ Installa una nuova azione per il segnale \param{signum}.
+
+ \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
+ errore, nel qual caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] Si è specificato un numero di segnale invalido o si è
+ cercato di installare il gestore per \const{SIGKILL} o
+ \const{SIGSTOP}.
+ \item[\errcode{EFAULT}] Si sono specificati indirizzi non validi.
+ \end{errlist}}
+\end{prototype}
+
+La funzione serve ad installare una nuova \textsl{azione} per il segnale
+\param{signum}; si parla di \textsl{azione} e non di \textsl{gestore}
+come nel caso di \func{signal}, in quanto la funzione consente di specificare
+le varie caratteristiche della risposta al segnale, non solo la funzione che
+verrà eseguita alla sua occorrenza. Per questo lo standard raccomanda di
+usare sempre questa funzione al posto di \func{signal} (che in genere viene
+definita tramite essa), in quanto permette un controllo completo su tutti gli
+aspetti della gestione di un segnale, sia pure al prezzo di una maggiore
+complessità d'uso.
+
+Se il puntatore \param{act} non è nullo, la funzione installa la nuova azione
+da esso specificata, se \param{oldact} non è nullo il valore dell'azione
+corrente viene restituito indietro. Questo permette (specificando \param{act}
+nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
+che non consente di ottenere l'azione corrente senza installarne una nuova.
+
+Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
+tramite la quale si specificano tutte le caratteristiche dell'azione associata
+ad un segnale. Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
+definita secondo quanto riportato in \figref{fig:sig_sigaction}. Il campo
+\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
+più usato.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includestruct{listati/sigaction.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{sigaction}.}
+ \label{fig:sig_sigaction}
+\end{figure}
+
+Il campo \var{sa\_mask} serve ad indicare l'insieme dei segnali che devono
+essere bloccati durante l'esecuzione del gestore, ad essi viene comunque
+sempre aggiunto il segnale che ne ha causato la chiamata, a meno che non si
+sia specificato con \var{sa\_flag} un comportamento diverso. Quando il
+gestore ritorna comunque la maschera dei segnali bloccati (vedi
+\secref{sec:sig_sigmask}) viene ripristinata al valore precedente
+l'invocazione.
+
+L'uso di questo campo permette ad esempio di risolvere il problema residuo
+dell'implementazione di \code{sleep} mostrata in
+\secref{fig:sig_sleep_incomplete}. In quel caso infatti se il segnale di
+allarme avesse interrotto un altro gestore questo non sarebbe stato
+eseguito correttamente; la cosa poteva essere prevenuta installando gli altri
+gestori usando \var{sa\_mask} per bloccare \const{SIGALRM} durante la
+loro esecuzione. Il valore di \var{sa\_flag} permette di specificare vari
+aspetti del comportamento di \func{sigaction}, e della reazione del processo
+ai vari segnali; i valori possibili ed il relativo significato sono riportati
+in \tabref{tab:sig_sa_flag}.