+Raccogliamo qui infine una serie di segnali che hanno scopi differenti non
+classificabili in maniera omogenea. Questi segnali sono:
+\begin{basedescript}{\desclabelwidth{2.0cm}}
+\item[\const{SIGUSR1}] Insieme a \const{SIGUSR2} è un segnale a disposizione
+ dell'utente che lo può usare per quello che vuole. Viene generato solo
+ attraverso l'invocazione della funzione \func{kill}. Entrambi i segnali
+ possono essere utili per implementare una comunicazione elementare fra
+ processi diversi, o per eseguire a richiesta una operazione utilizzando un
+ gestore. L'azione predefinita è di terminare il processo.
+\item[\const{SIGUSR2}] È il secondo segnale a dispozione degli utenti. Vedi
+ quanto appena detto per \const{SIGUSR1}.
+\item[\const{SIGWINCH}] Il nome sta per \textit{window (size) change} e viene
+ generato in molti sistemi (GNU/Linux compreso) quando le dimensioni (in
+ righe e colonne) di un terminale vengono cambiate. Viene usato da alcuni
+ programmi testuali per riformattare l'uscita su schermo quando si cambia
+ dimensione a quest'ultimo. L'azione predefinita è di essere ignorato.
+\item[\const{SIGINFO}] Il segnale indica una richiesta di informazioni. È
+ usato con il controllo di sessione, causa la stampa di informazioni da parte
+ del processo leader del gruppo associato al terminale di controllo, gli
+ altri processi lo ignorano.
+\end{basedescript}
+
+
+\subsection{Le funzioni \func{strsignal} e \func{psignal}}
+\label{sec:sig_strsignal}
+
+Per la descrizione dei segnali il sistema mette a disposizione due funzioni
+che stampano un messaggio di descrizione dato il numero. In genere si usano
+quando si vuole notificare all'utente il segnale ricevuto (nel caso di
+terminazione di un processo figlio o di un gestore che gestisce più segnali);
+la prima funzione, \funcd{strsignal}, è una estensione GNU, accessibile avendo
+definito \macro{\_GNU\_SOURCE}, ed è analoga alla funzione \func{strerror} (si
+veda sez.~\ref{sec:sys_strerror}) per gli errori:
+\begin{prototype}{string.h}{char *strsignal(int signum)}
+ Ritorna il puntatore ad una stringa che contiene la descrizione del segnale
+ \param{signum}.
+\end{prototype}
+\noindent dato che la stringa è allocata staticamente non se ne deve
+modificare il contenuto, che resta valido solo fino alla successiva chiamata
+di \func{strsignal}. Nel caso si debba mantenere traccia del messaggio sarà
+necessario copiarlo.
+
+La seconda funzione, \funcd{psignal}, deriva da BSD ed è analoga alla funzione
+\func{perror} descritta sempre in sez.~\ref{sec:sys_strerror}; il suo prototipo
+è:
+\begin{prototype}{signal.h}{void psignal(int sig, const char *s)}
+ Stampa sullo standard error un messaggio costituito dalla stringa \param{s},
+ seguita da due punti ed una descrizione del segnale indicato da \param{sig}.
+\end{prototype}
+
+Una modalità alternativa per utilizzare le descrizioni restituite da
+\func{strsignal} e \func{psignal} è quello di usare la variabile
+\var{sys\_siglist}, che è definita in \file{signal.h} e può essere acceduta
+con la dichiarazione:
+\includecodesnip{listati/siglist.c}
+
+L'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
+indicizzate per numero di segnale, per cui una chiamata del tipo di \code{char
+ *decr = strsignal(SIGINT)} può essere sostituita dall'equivalente \code{char
+ *decr = sys\_siglist[SIGINT]}.
+
+
+
+\section{La gestione dei segnali}
+\label{sec:sig_management}
+
+I segnali sono il primo e più classico esempio di eventi asincroni, cioè di
+eventi che possono accadere in un qualunque momento durante l'esecuzione di un
+programma. Per questa loro caratteristica la loro gestione non può essere
+effettuata all'interno del normale flusso di esecuzione dello stesso, ma è
+delegata appunto agli eventuali gestori che si sono installati.
+
+In questa sezione vedremo come si effettua la gestione dei segnali, a partire
+dalla loro interazione con le system call, passando per le varie funzioni che
+permettono di installare i gestori e controllare le reazioni di un processo
+alla loro occorrenza.
+
+
+\subsection{Il comportamento generale del sistema}
+\label{sec:sig_gen_beha}
+
+Abbiamo già trattato in sez.~\ref{sec:sig_intro} le modalità con cui il sistema
+gestisce l'interazione fra segnali e processi, ci resta da esaminare però il
+comportamento delle system call; in particolare due di esse, \func{fork} ed
+\func{exec}, dovranno essere prese esplicitamente in considerazione, data la
+loro stretta relazione con la creazione di nuovi processi.
+
+Come accennato in sez.~\ref{sec:proc_fork} quando viene creato un nuovo
+processo esso eredita dal padre sia le azioni che sono state impostate per i
+singoli segnali, che la maschera dei segnali bloccati (vedi
+sez.~\ref{sec:sig_sigmask}). Invece tutti i segnali pendenti e gli allarmi
+vengono cancellati; essi infatti devono essere recapitati solo al padre, al
+figlio dovranno arrivare solo i segnali dovuti alle sue azioni.
+
+Quando si mette in esecuzione un nuovo programma con \func{exec} (si ricordi
+quanto detto in sez.~\ref{sec:proc_exec}) tutti i segnali per i quali è stato
+installato un gestore vengono reimpostati a \const{SIG\_DFL}. Non ha più
+senso infatti fare riferimento a funzioni definite nel programma originario,
+che non sono presenti nello spazio di indirizzi del nuovo programma.
+
+Si noti che questo vale solo per le azioni per le quali è stato installato un
+gestore; viene mantenuto invece ogni eventuale impostazione dell'azione a
+\const{SIG\_IGN}. Questo permette ad esempio alla shell di impostare ad
+\const{SIG\_IGN} le risposte per \const{SIGINT} e \const{SIGQUIT} per i
+programmi eseguiti in background, che altrimenti sarebbero interrotti da una
+successiva pressione di \texttt{C-c} o \texttt{C-y}.
+
+Per quanto riguarda il comportamento di tutte le altre system call si danno
+sostanzialmente due casi, a seconda che esse siano\index{system~call~lente}
+\textsl{lente} (\textit{slow}) o \textsl{veloci} (\textit{fast}). La gran
+parte di esse appartiene a quest'ultima categoria, che non è influenzata
+dall'arrivo di un segnale. Esse sono dette \textsl{veloci} in quanto la loro
+esecuzione è sostanzialmente immediata; la risposta al segnale viene sempre
+data dopo che la system call è stata completata, in quanto attendere per
+eseguire un gestore non comporta nessun inconveniente.
+
+In alcuni casi però alcune system call (che per questo motivo vengono chiamate
+\textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può
+attendere la conclusione della system call, perché questo renderebbe
+impossibile una risposta pronta al segnale, per cui il gestore viene
+eseguito prima che la system call sia ritornata. Un elenco dei casi in cui si
+presenta questa situazione è il seguente:
+\begin{itemize*}
+\item la lettura da file che possono bloccarsi in attesa di dati non ancora
+ presenti (come per certi file di dispositivo\index{file!di~dispositivo}, i
+ socket\index{socket} o le pipe);
+\item la scrittura sugli stessi file, nel caso in cui dati non possano essere
+ accettati immediatamente (di nuovo comune per i socket);
+\item l'apertura di un file di dispositivo che richiede operazioni non
+ immediate per una risposta (ad esempio l'apertura di un nastro che deve
+ essere riavvolto);
+\item le operazioni eseguite con \func{ioctl} che non è detto possano essere
+ eseguite immediatamente;
+\item le funzioni di intercomunicazione che si bloccano in attesa di risposte
+ da altri processi;
+\item la funzione \func{pause} (usata appunto per attendere l'arrivo di un
+ segnale);
+\item la funzione \func{wait} (se nessun processo figlio è ancora terminato).
+\end{itemize*}
+
+In questo caso si pone il problema di cosa fare una volta che il gestore sia
+ritornato. La scelta originaria dei primi Unix era quella di far ritornare
+anche la system call restituendo l'errore di \errcode{EINTR}. Questa è a
+tutt'oggi una scelta corrente, ma comporta che i programmi che usano dei
+gestori controllino lo stato di uscita delle funzioni che eseguono una system
+call lenta per ripeterne la chiamata qualora l'errore fosse questo.
+
+Dimenticarsi di richiamare una system call interrotta da un segnale è un
+errore comune, tanto che le \acr{glibc} provvedono una macro
+\code{TEMP\_FAILURE\_RETRY(expr)} che esegue l'operazione automaticamente,
+ripetendo l'esecuzione dell'espressione \var{expr} fintanto che il risultato
+non è diverso dall'uscita con un errore \errcode{EINTR}.
+
+La soluzione è comunque poco elegante e BSD ha scelto un approccio molto
+diverso, che è quello di fare ripartire automaticamente una system call
+interrotta invece di farla fallire. In questo caso ovviamente non c'è bisogno
+di preoccuparsi di controllare il codice di errore; si perde però la
+possibilità di eseguire azioni specifiche all'occorrenza di questa particolare
+condizione.
+
+Linux e le \acr{glibc} consentono di utilizzare entrambi gli approcci,
+attraverso una opportuna opzione di \func{sigaction} (vedi
+sez.~\ref{sec:sig_sigaction}). È da chiarire comunque che nel caso di
+interruzione nel mezzo di un trasferimento parziale di dati, le system call
+ritornano sempre indicando i byte trasferiti.
+
+
+\subsection{La funzione \func{signal}}
+\label{sec:sig_signal}
+
+L'interfaccia più semplice per la gestione dei segnali è costituita dalla
+funzione \funcd{signal} che è definita fin dallo standard ANSI C.
+Quest'ultimo però non considera sistemi multitasking, per cui la definizione è
+tanto vaga da essere del tutto inutile in un sistema Unix; è questo il motivo
+per cui ogni implementazione successiva ne ha modificato e ridefinito il
+comportamento, pur mantenendone immutato il prototipo\footnote{in realtà in
+ alcune vecchie implementazioni (SVr4 e 4.3+BSD in particolare) vengono usati
+ alcuni argomenti aggiuntivi per definire il comportamento della funzione,
+ vedremo in sez.~\ref{sec:sig_sigaction} che questo è possibile usando la
+ funzione \func{sigaction}.} che è:
+\begin{prototype}{signal.h}
+ {sighandler\_t signal(int signum, sighandler\_t handler)}
+
+ Installa la funzione di gestione \param{handler} (il gestore) per il
+ segnale \param{signum}.
+
+ \bodydesc{La funzione ritorna il precedente gestore in caso di successo
+ o \const{SIG\_ERR} in caso di errore.}
+\end{prototype}
+
+In questa definizione si è usato un tipo di dato, \type{sighandler\_t}, che è
+una estensione GNU, definita dalle \acr{glibc}, che permette di riscrivere il
+prototipo di \func{signal} nella forma appena vista, molto più leggibile di
+quanto non sia la versione originaria, che di norma è definita come:
+\includecodesnip{listati/signal.c}
+questa infatti, per la poca chiarezza della sintassi del C quando si vanno a
+trattare puntatori a funzioni, è molto meno comprensibile. Da un confronto
+con il precedente prototipo si può dedurre la definizione di
+\type{sighandler\_t} che è:
+\includecodesnip{listati/sighandler_t.c}
+e cioè un puntatore ad una funzione \ctyp{void} (cioè senza valore di ritorno)
+e che prende un argomento di tipo \ctyp{int}.\footnote{si devono usare le
+ parentesi intorno al nome della funzione per via delle precedenze degli
+ operatori del C, senza di esse si sarebbe definita una funzione che ritorna
+ un puntatore a \ctyp{void} e non un puntatore ad una funzione \ctyp{void}.}
+La funzione \func{signal} quindi restituisce e prende come secondo argomento
+un puntatore a una funzione di questo tipo, che è appunto il gestore del
+segnale.
+
+Il numero di segnale passato in \param{signum} può essere indicato
+direttamente con una delle costanti definite in sez.~\ref{sec:sig_standard}. Il
+gestore \param{handler} invece, oltre all'indirizzo della funzione da chiamare
+all'occorrenza del segnale, può assumere anche i due valori costanti
+\const{SIG\_IGN} con cui si dice di ignorare il segnale e \const{SIG\_DFL} per
+reinstallare l'azione predefinita.\footnote{si ricordi però che i due segnali
+ \const{SIGKILL} e \const{SIGSTOP} non possono essere né ignorati né
+ intercettati; l'uso di \const{SIG\_IGN} per questi segnali non ha alcun
+ effetto.}
+
+La funzione restituisce l'indirizzo dell'azione precedente, che può essere
+salvato per poterlo ripristinare (con un'altra chiamata a \func{signal}) in un
+secondo tempo. Si ricordi che se si imposta come azione \const{SIG\_IGN} (o si
+imposta un \const{SIG\_DFL} per un segnale la cui azione predefinita è di
+essere ignorato), tutti i segnali pendenti saranno scartati, e non verranno
+mai notificati.
+
+L'uso di \func{signal} è soggetto a problemi di compatibilità, dato che essa
+si comporta in maniera diversa per sistemi derivati da BSD o da System V. In
+questi ultimi infatti la funzione è conforme al comportamento originale dei
+primi Unix in cui il gestore viene disinstallato alla sua chiamata, secondo la
+semantica inaffidabile; anche Linux seguiva questa convenzione con le vecchie
+librerie del C come le \acr{libc4} e le \acr{libc5}.\footnote{nelle
+ \acr{libc5} esiste però la possibilità di includere \file{bsd/signal.h} al
+ posto di \file{signal.h}, nel qual caso la funzione \func{signal} viene
+ ridefinita per seguire la semantica affidabile usata da BSD.}
+
+Al contrario BSD segue la semantica affidabile, non disinstallando il gestore
+e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo delle
+\acr{glibc} dalla versione 2 anche Linux è passato a questo comportamento. Il
+comportamento della versione originale della funzione, il cui uso è deprecato
+per i motivi visti in sez.~\ref{sec:sig_semantics}, può essere ottenuto
+chiamando \func{sysv\_signal}, una volta che si sia definita la macro
+\macro{\_XOPEN\_SOURCE}. In generale, per evitare questi problemi, l'uso di
+\func{signal} (ed ogni eventuale ridefinizine della stessa) è da evitare;
+tutti i nuovi programmi dovrebbero usare \func{sigaction}.
+
+È da tenere presente che, seguendo lo standard POSIX, il comportamento di un
+processo che ignora i segnali \const{SIGFPE}, \const{SIGILL}, o
+\const{SIGSEGV} (qualora questi non originino da una chiamata ad una
+\func{kill} o ad una \func{raise}) è indefinito. Un gestore che ritorna da
+questi segnali può dare luogo ad un ciclo infinito.
+
+
+\subsection{Le funzioni \func{kill} e \func{raise}}
+\label{sec:sig_kill_raise}
+
+Come accennato in sez.~\ref{sec:sig_types}, un segnale può essere generato
+direttamente da un processo attraverso una opportuna system call. Le funzioni
+che si usano di solito per inviare un segnale generico sono due, \func{raise} e
+\func{kill}.
+
+La prima funzione è \funcd{raise}, che è definita dallo standard ANSI C, e
+serve per inviare un segnale al processo corrente,\footnote{non prevedendo la
+ presenza di un sistema multiutente lo standard ANSI C non poteva che
+ definire una funzione che invia il segnale al programma in esecuzione. Nel
+ caso di Linux questa viene implementata come funzione di compatibilità.} il
+suo prototipo è:
+\begin{prototype}{signal.h}{int raise(int sig)}
+ Invia il segnale \param{sig} al processo corrente.
+
+ \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
+ errore, il solo errore restituito è \errval{EINVAL} qualora si sia
+ specificato un numero di segnale invalido.}
+\end{prototype}
+
+Il valore di \param{sig} specifica il segnale che si vuole inviare e può
+essere specificato con una delle macro definite in
+sez.~\ref{sec:sig_classification}. In genere questa funzione viene usata per
+riprodurre il comportamento predefinito di un segnale che sia stato
+intercettato. In questo caso, una volta eseguite le operazioni volute, il
+gestore dovrà prima reinstallare l'azione predefinita, per poi attivarla
+chiamando \func{raise}.
+
+Mentre \func{raise} è una funzione di libreria, quando si vuole inviare un
+segnale generico ad un processo occorre utilizzare la apposita system call,
+questa può essere chiamata attraverso la funzione \funcd{kill}, il cui
+prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{signal.h}
+ \funcdecl{int kill(pid\_t pid, int sig)} Invia il segnale \param{sig} al
+ processo specificato con \param{pid}.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ errore nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] Il segnale specificato non esiste.
+ \item[\errcode{ESRCH}] Il processo selezionato non esiste.
+ \item[\errcode{EPERM}] Non si hanno privilegi sufficienti ad inviare il
+ segnale.
+ \end{errlist}}
+\end{functions}
+
+Lo standard POSIX prevede che il valore 0 per \param{sig} sia usato per
+specificare il segnale nullo. Se la funzione viene chiamata con questo valore
+non viene inviato nessun segnale, ma viene eseguito il controllo degli errori,
+in tal caso si otterrà un errore \errcode{EPERM} se non si hanno i permessi
+necessari ed un errore \errcode{ESRCH} se il processo specificato non esiste.
+Si tenga conto però che il sistema ricicla i \acr{pid} (come accennato in
+sez.~\ref{sec:proc_pid}) per cui l'esistenza di un processo non significa che
+esso sia realmente quello a cui si intendeva mandare il segnale.
+
+Il valore dell'argomento \param{pid} specifica il processo (o i processi) di
+destinazione a cui il segnale deve essere inviato e può assumere i valori
+riportati in tab.~\ref{tab:sig_kill_values}.
+
+Si noti pertanto che la funzione \code{raise(sig)} può essere definita in
+termini di \func{kill}, ed è sostanzialmente equivalente ad una
+\code{kill(getpid(), sig)}. Siccome \func{raise}, che è definita nello
+standard ISO C, non esiste in alcune vecchie versioni di Unix, in generale
+l'uso di \func{kill} finisce per essere più portabile.
+
+Una seconda funzione che può essere definita in termini di \func{kill} è
+\funcd{killpg}, che è sostanzialmente equivalente a
+\code{kill(-pidgrp, signal)}; il suo prototipo è:
+\begin{prototype}{signal.h}{int killpg(pid\_t pidgrp, int signal)}
+
+ Invia il segnale \param{signal} al process group \param{pidgrp}.
+ \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ errore, gli errori sono gli stessi di \func{kill}.}
+\end{prototype}
+\noindent e permette di inviare un segnale a tutto un \textit{process group}
+(vedi sez.~\ref{sec:sess_proc_group}).
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|r|l|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ $>0$ & il segnale è mandato al processo con il \acr{pid} indicato.\\
+ 0 & il segnale è mandato ad ogni processo del \textit{process group}
+ del chiamante.\\
+ $-1$ & il segnale è mandato ad ogni processo (eccetto \cmd{init}).\\
+ $<-1$ & il segnale è mandato ad ogni processo del process group
+ $|\code{pid}|$.\\
+ \hline
+ \end{tabular}
+ \caption{Valori dell'argomento \param{pid} per la funzione
+ \func{kill}.}
+ \label{tab:sig_kill_values}
+\end{table}
+
+Solo l'amministratore può inviare un segnale ad un processo qualunque, in
+tutti gli altri casi l'user-ID reale o l'user-ID effettivo del processo
+chiamante devono corrispondere all'user-ID reale o all'user-ID salvato della
+destinazione. Fa eccezione il caso in cui il segnale inviato sia
+\const{SIGCONT}, nel quale occorre che entrambi i processi appartengano alla
+stessa sessione. Inoltre, dato il ruolo fondamentale che riveste nel sistema
+(si ricordi quanto visto in sez.~\ref{sec:sig_termination}), non è possibile
+inviare al processo 1 (cioè a \cmd{init}) segnali per i quali esso non abbia
+un gestore installato.
+
+Infine, seguendo le specifiche POSIX 1003.1-2001, l'uso della chiamata
+\code{kill(-1, sig)} comporta che il segnale sia inviato (con la solita
+eccezione di \cmd{init}) a tutti i processi per i quali i permessi lo
+consentano. Lo standard permette comunque alle varie implementazioni di
+escludere alcuni processi specifici: nel caso in questione Linux non invia il
+segnale al processo che ha effettuato la chiamata.
+
+
+\subsection{Le funzioni \func{alarm} e \func{abort}}
+\label{sec:sig_alarm_abort}
+
+Un caso particolare di segnali generati a richiesta è quello che riguarda i
+vari segnali di temporizzazione e \const{SIGABRT}, per ciascuno di questi
+segnali sono previste funzioni specifiche che ne effettuino l'invio. La più
+comune delle funzioni usate per la temporizzazione è \funcd{alarm} il cui
+prototipo è:
+\begin{prototype}{unistd.h}{unsigned int alarm(unsigned int seconds)}
+ Predispone l'invio di \const{SIGALRM} dopo \param{seconds} secondi.
+
+ \bodydesc{La funzione restituisce il numero di secondi rimanenti ad un
+ precedente allarme, o zero se non c'erano allarmi pendenti.}
+\end{prototype}
+
+La funzione fornisce un meccanismo che consente ad un processo di predisporre
+un'interruzione nel futuro, (ad esempio per effettuare una qualche operazione
+dopo un certo periodo di tempo), programmando l'emissione di un segnale (nel
+caso in questione \const{SIGALRM}) dopo il numero di secondi specificato da
+\param{seconds}.
+
+Se si specifica per \param{seconds} un valore nullo non verrà inviato nessun
+segnale; siccome alla chiamata viene cancellato ogni precedente allarme,
+questo può essere usato per cancellare una programmazione precedente.
+
+La funzione inoltre ritorna il numero di secondi rimanenti all'invio
+dell'allarme programmato in precedenza. In questo modo è possibile controllare
+se non si è cancellato un precedente allarme e predisporre eventuali misure
+che permettano di gestire il caso in cui servono più interruzioni.
+
+In sez.~\ref{sec:sys_unix_time} abbiamo visto che ad ogni processo sono
+associati tre tempi diversi: il \textit{clock time}, l'\textit{user time} ed
+il \textit{system time}. Per poterli calcolare il kernel mantiene per ciascun
+processo tre diversi timer:
+\begin{itemize}
+\item un \textit{real-time timer} che calcola il tempo reale trascorso (che
+ corrisponde al \textit{clock time}). La scadenza di questo timer provoca
+ l'emissione di \const{SIGALRM};
+\item un \textit{virtual timer} che calcola il tempo di processore usato dal
+ processo in user space (che corrisponde all'\textit{user time}). La scadenza
+ di questo timer provoca l'emissione di \const{SIGVTALRM};
+\item un \textit{profiling timer} che calcola la somma dei tempi di processore
+ utilizzati direttamente dal processo in user space, e dal kernel nelle
+ system call ad esso relative (che corrisponde a quello che in
+ sez.~\ref{sec:sys_unix_time} abbiamo chiamato \textit{CPU time}). La scadenza
+ di questo timer provoca l'emissione di \const{SIGPROF}.
+\end{itemize}
+
+Il timer usato da \func{alarm} è il \textit{clock time}, e corrisponde cioè al
+tempo reale. La funzione come abbiamo visto è molto semplice, ma proprio per
+questo presenta numerosi limiti: non consente di usare gli altri timer, non
+può specificare intervalli di tempo con precisione maggiore del secondo e
+genera il segnale una sola volta.
+
+Per ovviare a questi limiti Linux deriva da BSD la funzione \funcd{setitimer}
+che permette di usare un timer qualunque e l'invio di segnali periodici, al
+costo però di una maggiore complessità d'uso e di una minore portabilità. Il
+suo prototipo è:
+\begin{prototype}{sys/time.h}{int setitimer(int which, const struct
+ itimerval *value, struct itimerval *ovalue)}
+
+ Predispone l'invio di un segnale di allarme alla scadenza dell'intervallo
+ \param{value} sul timer specificato da \param{which}.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei valori \errval{EINVAL} o
+ \errval{EFAULT}.}
+\end{prototype}
+
+Il valore di \param{which} permette di specificare quale dei tre timer
+illustrati in precedenza usare; i possibili valori sono riportati in
+tab.~\ref{tab:sig_setitimer_values}.
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Valore} & \textbf{Timer} \\
+ \hline
+ \hline
+ \const{ITIMER\_REAL} & \textit{real-time timer}\\
+ \const{ITIMER\_VIRTUAL} & \textit{virtual timer}\\
+ \const{ITIMER\_PROF} & \textit{profiling timer}\\
+ \hline
+ \end{tabular}
+ \caption{Valori dell'argomento \param{which} per la funzione
+ \func{setitimer}.}
+ \label{tab:sig_setitimer_values}
+\end{table}
+
+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 fig.~\ref{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
+fig.~\ref{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 sez.~\ref{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 \param{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 argomenti 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 sez.~\ref{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{atexit} 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
+ sez.~\ref{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 sez.~\ref{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 argomenti
+delle strutture di tipo \struct{timespec}, la cui definizione è riportata in
+fig.~\ref{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{\textit{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
+sez.~\ref{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 di chiamare
+\func{waitpid} per completare la procedura di terminazione in modo da evitare
+la formazione di zombie\index{zombie}.
+
+In fig.~\ref{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 sez.~\ref{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}.
+
+\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 sez.~\ref{sec:sys_errno}) si
+comincia (\texttt{\small 6--7}) con il salvare lo stato corrente di
+\var{errno}, in modo da poterlo ripristinare prima del ritorno del gestore
+(\texttt{\small 16--17}). In questo modo si preserva il valore della variabile
+visto dal corso di esecuzione principale del processo, che altrimenti sarebbe
+sovrascritto dal valore restituito nella successiva chiamata di \func{waitpid}.
+
+Il compito principale del gestore è quello di ricevere lo stato di
+terminazione del processo, cosa che viene eseguita nel ciclo in
+(\texttt{\small 9--15}). 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 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 verrà 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 sez.~\ref{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 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{\textit{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 sez.~\ref{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
+fig.~\ref{fig:sig_sleep_wrong}.
+
+Dato che è nostra intenzione utilizzare \const{SIGALRM} il primo passo della
+nostra implementazione 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
+ 18-20}) 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 21-22}) restituendo l'eventuale tempo rimanente
+(\texttt{\small 23-24}) 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{\textit{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 di quest'ultima, cosicché essa
+sarebbe eseguita dopo l'arrivo di \const{SIGALRM}. In questo caso ci si
+troverebbe di fronte ad un deadlock\index{\textit{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 sez.~\ref{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 fig.~\ref{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-27}) non ritorna come in
+fig.~\ref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 25}) 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
+fig.~\ref{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
+sez.~\ref{sec:proc_race_cond}, in cui si genera una
+\index{\textit{race~condition}}race condition; infatti, in una situazione in
+cui un segnale è già arrivato (e \var{flag} è già ad 1) se un altro segnale
+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}
+
+\index{\textit{signal~set}|(}
+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 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 ottenere 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), tale tipo di dato viene usato per gestire il
+blocco dei segnali.
+
+In genere un \textsl{insieme di segnali} è rappresentato da un intero di
+dimensione opportuna, di solito 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}.