+\fdesc{Predispone l'invio di un segnale di allarme.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori \errval{EINVAL} o \errval{EFAULT}
+ nel loro significato generico.}
+\end{funcproto}
+
+
+La funzione predispone l'invio di un segnale di allarme alla scadenza
+dell'intervallo indicato dall'argomento \param{value}. Il valore
+dell'argomento \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
+ \constd{ITIMER\_REAL} & \textit{real-time timer}\\
+ \constd{ITIMER\_VIRTUAL} & \textit{virtual timer}\\
+ \constd{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]{0.8\textwidth}
+ \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 della \acr{glibc}
+\cite{GlibcMan} che ne riporta la definizione mostrata in
+fig.~\ref{fig:sig_alarm_def}.\footnote{questo comporta anche che non è il caso
+ di mescolare chiamate ad \func{abort} e a \func{setitimer}.}
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \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 fino al kernel 2.6.16 la precisione di
+queste funzioni era limitata dalla frequenza del timer di sistema, determinato
+dal valore della costante \texttt{HZ} di cui abbiamo già parlato in
+sez.~\ref{sec:proc_hierarchy}, in quanto le temporizzazioni erano calcolate in
+numero di interruzioni del timer (i cosiddetti ``\textit{jiffies}''), ed era
+assicurato soltanto che il segnale non sarebbe stato mai generato prima della
+scadenza programmata (l'arrotondamento cioè era effettuato per
+eccesso).\footnote{questo in realtà non è del tutto vero a causa di un bug,
+ presente fino al kernel 2.6.12, che in certe circostanze causava l'emissione
+ del segnale con un arrotondamento per difetto.}
+
+L'uso del contatore dei \textit{jiffies}, un intero a 32 bit nella maggior
+parte dei casi, comportava inoltre l'impossibilità di specificare tempi molto
+lunghi. superiori al valore della costante \constd{MAX\_SEC\_IN\_JIFFIES},
+pari, nel caso di default di un valore di \const{HZ} di 250, a circa 99 giorni
+e mezzo. Con il cambiamento della rappresentazione effettuato nel kernel
+2.6.16 questo problema è scomparso e con l'introduzione dei timer ad alta
+risoluzione (vedi sez.~\ref{sec:sig_timer_adv}) nel kernel 2.6.21 la
+precisione è diventata quella fornita dall'hardware disponibile.
+
+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\_VIRTUAL}) 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. Per questo
+oggi l'uso di questa funzione è deprecato a favore degli
+\textit{high-resolution timer} e della cosiddetta \textit{POSIX Timer API},
+che tratteremo in sez.~\ref{sec:sig_timer_adv}.
+
+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{funcproto}{
+\fhead{sys/time.h}
+\fdecl{int getitimer(int which, struct itimerval *value)}
+\fdesc{Legge il valore di un timer.}
+}
+
+{ La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà gli stessi valori di \func{getitimer}. }
+\end{funcproto}
+
+La funzione legge nella struttura \struct{itimerval} puntata da \param{value}
+il valore del timer specificato da \param{which} ed i suoi argomenti hanno lo
+stesso significato e formato di quelli di \func{setitimer}.
+
+
+\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 ciclo di attesa in cui il programma ripete
+una operazione un numero sufficiente di volte per far passare il tempo
+richiesto.
+
+Ma in un sistema multitasking un ciclo di attesa è solo un inutile spreco di
+tempo di processore dato che altri programmi possono essere eseguiti nel
+frattempo, per questo ci sono delle apposite funzioni che permettono di
+mantenere un processo in attesa per il tempo voluto, senza impegnare il
+processore. In pratica si tratta di funzioni che permettono di portare
+esplicitamente il processo nello stato di \textit{sleep} (si ricordi quanto
+illustrato in tab.~\ref{tab:proc_proc_states}) per un certo periodo di tempo.
+
+La prima di queste è la funzione di sistema \funcd{pause}, che viene usata per
+mettere un processo in attesa per un periodo di tempo indefinito, fino
+all'arrivo di un segnale, il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int pause(void)}
+\fdesc{Pone il processo in pausa fino al ricevimento di un segnale.}
+}
+
+{La funzione ritorna solo dopo che un segnale è stato ricevuto ed il relativo
+ gestore è ritornato, nel qual caso restituisce $-1$ e \var{errno} assume il
+ valore \errval{EINTR}.}
+\end{funcproto}
+
+La funzione ritorna sempre con una condizione di errore, dato che il successo
+sarebbe quello di continuare ad 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 in partenza, lo standard POSIX.1 prevede una funzione di attesa
+specifica, \funcd{sleep}, il cui prototipo è:
+
+\begin{funcproto}{
+
+\fhead{unistd.h}
+\fdecl{unsigned int sleep(unsigned int seconds)}
+\fdesc{Pone il processo in pausa per un tempo in secondi.}
+}
+
+{La funzione ritorna $0$ se l'attesa viene completata o il
+ numero di secondi restanti se viene interrotta da un segnale, non sono
+ previsti codici di errore.}
+\end{funcproto}
+
+La funzione pone il processo in stato di \textit{sleep} per il numero di
+secondi specificato dall'argomento \param{seconds}, a meno di non essere
+interrotta da un segnale. Alla terminazione del periodo di tempo indicato la
+funzione ritorna riportando il processo in stato \textit{runnable} così che
+questo possa riprendere l'esecuzione.
+
+In caso di interruzione della funzione non è una buona idea ripetere la
+chiamata per il tempo rimanente restituito dalla stessa, in quanto la
+riattivazione del processo può avvenire in un qualunque momento, ma il valore
+restituito sarà sempre arrotondato al secondo. Questo può avere la conseguenza
+che se la successione dei segnali è particolarmente sfortunata e le differenze
+si accumulano, si possono avere ritardi anche di parecchi secondi rispetto a
+quanto programmato inizialmente. In genere la scelta più sicura in questo caso
+è quella di stabilire un termine per l'attesa, e ricalcolare tutte le volte il
+numero di secondi che restano da aspettare.
+
+Si tenga presente che alcune implementazioni l'uso di \func{sleep} può avere
+conflitti con quello di \signal{SIGALRM}, dato che la funzione può essere
+realizzata con l'uso di \func{pause} e \func{alarm}, in una maniera analoga a
+quella dell'esempio che vedremo in sez.~\ref{sec:sig_example}. In tal caso
+mescolare chiamate di \func{alarm} e \func{sleep} o modificare l'azione
+associata \signal{SIGALRM}, può portare a dei risultati indefiniti. Nel caso
+della \acr{glibc} è stata usata una implementazione completamente indipendente
+e questi problemi non ci sono, ma un programma portabile non può fare questa
+assunzione.
+
+La granularità di \func{sleep} permette di specificare attese soltanto in
+secondi, per questo sia sotto BSD4.3 che in SUSv2 è stata definita un'altra
+funzione con una precisione teorica del microsecondo. I due standard hanno
+delle definizioni diverse, ma la \acr{glibc} segue (secondo la pagina di
+manuale almeno dalla versione 2.2.2) quella di SUSv2 per cui la
+funzione \funcd{usleep} (dove la \texttt{u} è intesa come sostituzione di
+$\mu$), ha il seguente prototipo:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int usleep(unsigned long usec)}
+\fdesc{Pone il processo in pausa per un tempo in microsecondi.}
+}
+
+{La funzione ritorna $0$ se l'attesa viene completata e $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINVAL}] si è indicato un valore di \param{usec} maggiore di
+ 1000000.
+ \end{errlist}
+}
+\end{funcproto}
+
+Anche questa funzione, a seconda delle implementazioni, può presentare
+problemi nell'interazione con \func{alarm} e \signal{SIGALRM}, per questo
+motivo, pur essendovi citata, nello standard POSIX.1-2001 viene deprecata in
+favore della nuova funzione di sistema \funcd{nanosleep}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int nanosleep(const struct timespec *req, struct timespec *rem)}
+\fdesc{Pone il processo in pausa per un intervallo di tempo.}
+}
+
+{La funzione ritorna $0$ se l'attesa viene completata e $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINVAL}] si è specificato un numero di secondi negativo o un
+ numero di nanosecondi maggiore di 999.999.999.
+ \end{errlist}
+}
+\end{funcproto}
+
+La funzione pone il processo in pausa portandolo nello stato di \textit{sleep}
+per il tempo specificato dall'argomento \param{req}, ed in caso di
+interruzione restituisce il tempo restante nell'argomento \param{rem}. Lo
+standard richiede che la funzione sia implementata in maniera del tutto
+indipendente da \func{alarm}, e nel caso di Linux questo è fatto utilizzando
+direttamente il timer del kernel. Lo standard richiede inoltre che la funzione
+sia utilizzabile senza interferenze con l'uso di \signal{SIGALRM}. La funzione
+prende come argomenti delle strutture di tipo \struct{timespec}, la cui
+definizione è riportata in fig.~\ref{fig:sys_timespec_struct}, il che permette
+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,\footnote{con l'eccezione, valida solo nei kernel della serie
+ 2.4, in cui, per i processi riavviati dopo essere stati fermati da un
+ segnale, il tempo passato in stato \texttt{T} non viene considerato nel
+ calcolo della rimanenza.} e basta richiamare la funzione per completare
+l'attesa.
+
+Anche qui però occorre tenere presente che i tempi sono arrotondati, per cui
+la precisione, per quanto migliore di quella ottenibile con \func{sleep}, è
+relativa e in caso di molte interruzioni si può avere una deriva, per questo
+esiste la funzione \func{clock\_nanosleep} (vedi sez.~\ref{sec:sig_timer_adv})
+che permette di specificare un tempo assoluto anziché un tempo relativo.
+
+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 la successiva interruzione del timer di sistema,
+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}.
+
+Con i kernel della serie 2.4 in realtà era possibile ottenere anche pause più
+precise del centesimo di secondo usando politiche di \textit{scheduling}
+\textit{real-time} come \const{SCHED\_FIFO} o \const{SCHED\_RR} (vedi
+sez.~\ref{sec:proc_real_time}); in tal caso infatti il calcolo sul numero di
+interruzioni del timer veniva evitato utilizzando direttamente un ciclo di
+attesa con cui si raggiungevano pause fino ai 2~ms con precisioni del
+$\mu$s. Questa estensione è stata rimossa con i kernel della serie 2.6, che
+consentono una risoluzione più alta del timer di sistema; inoltre a partire
+dal kernel 2.6.21, \func{nanosleep} può avvalersi del supporto dei timer ad
+alta risoluzione, ottenendo la massima precisione disponibile sull'hardware
+della propria macchina.
+
+
+\subsection{Un esempio elementare}
+\label{sec:sig_sigchld}
+
+Un semplice esempio per illustrare il funzionamento di un gestore di segnale è
+quello della gestione di \signal{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. 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 \signal{SIGCHLD} il cui unico compito sia quello di chiamare
+\func{waitpid} per completare la procedura di terminazione in modo da evitare
+la formazione di \textit{zombie}.\footnote{si ricordi comunque che dal kernel
+ 2.6 seguendo lo standard POSIX.1-2001 per evitare di dover ricevere gli
+ stati di uscita che non interessano basta impostare come azione predefinita
+ quella di ignorare \signal{SIGCHLD}, nel qual caso viene assunta la
+ semantica di System V, in cui il segnale non viene inviato, il sistema non
+ genera \textit{zombie} e lo stato di terminazione viene scartato senza dover
+ chiamare una \func{wait}.}
+
+In fig.~\ref{fig:sig_sigchld_handl} è mostrato il codice contenente una
+implementazione generica di una funzione di gestione per \signal{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 \signal{SIGCHLD}) potremo verificare che non si ha
+più la creazione di \textit{zombie}.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/hand_sigchild.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice di una funzione generica di gestione per il segnale
+ \signal{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 \signal{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 \textit{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{La gestione avanzata dei segnali}
+\label{sec:sig_adv_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 \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}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/sleep_danger.c}
+ \end{minipage}
+ \normalsize
+ \caption{Una implementazione pericolosa di \func{sleep}.}
+ \label{fig:sig_sleep_wrong}
+\end{figure}
+
+Dato che è nostra intenzione utilizzare \signal{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.
+
+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 \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 \signal{SIGALRM}. In questo caso ci si troverebbe di fronte ad un
+\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]{\codesamplewidth}
+ \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 la funzione \func{longjmp}
+(\texttt{\small 25}) per rientrare direttamente nel corpo principale del
+programma. Dato che in questo caso il valore di uscita che verrà restituito da
+\func{setjmp} è 1, grazie alla condizione impostata in (\texttt{\small 9--12})
+si potrà evitare 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, 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 questa implementazione di \func{alarm} per stabilire un
+timeout su una qualunque \textit{system call} bloccante.
+
+Un secondo esempio dei problemi a cui si può andare incontro è quello in cui
+si usa un segnale per notificare una qualche forma di evento. In genere quello
+che si fa in questo caso è impostare all'interno del 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}.
+
+La logica del programma è quella di impostare nel gestore una variabile
+globale preventivamente inizializzata nel programma principale ad un valore
+diverso (\texttt{\small 14--19}). In questo modo dal corpo principale del
+programma si potrà determinare, osservando il contenuto di detta variabile,
+l'occorrenza o meno del segnale, ed eseguire le conseguenti azioni relative
+(\texttt{\small 6--11}).
+
+\begin{figure}[!htbp]
+ \footnotesize\centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \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}
+
+Questo è il tipico esempio di caso, già citato in
+sez.~\ref{sec:proc_race_cond}, in cui si genera una \textit{race
+ condition}. Infatti, in una situazione in cui un segnale è già arrivato (e
+quindi \var{flag} è già stata impostata ad 1 nel gestore) se un altro segnale
+arriva immediatamente dopo l'esecuzione del controllo (\texttt{\small 6}) ma
+prima della cancellazione di \var{flag} fatta subito dopo (\texttt{\small 7}),
+la sua occorrenza sarà perduta.
+
+Questi esempi ci mostrano come per poter eseguire una gestione effettiva dei
+segnali occorrono delle funzioni più sofisticate di quelle finora
+illustrate. La funzione \func{signal} infatti ha la sua origine
+nell'interfaccia alquanto primitiva che venne adottata nei primi sistemi Unix,
+ma con questa funzione è sostanzialmente impossibile gestire in maniera
+adeguata 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}
+
+\itindbeg{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.
+
+Inizialmente un \textsl{insieme di segnali} veniva rappresentato da un intero
+di dimensione opportuna, di solito pari al numero di bit dell'architettura
+della macchina, ciascun bit del quale era associato ad uno specifico
+segnale. Nel caso di architetture a 32 bit questo comporta un massimo di 32
+segnali distinti e dato che a lungo questi sono stati sufficienti non c'era
+necessità di nessuna struttura più complicata, in questo modo era possibile
+implementare le operazioni direttamente con istruzioni elementari del
+processore.
+
+Oggi questo non è più vero, in particolare con l'introduzione dei segnali
+\textit{real-rime} (che vedremo in sez.~\ref{sec:sig_real_time}). Dato che in
+generale non si può fare conto sulle caratteristiche di una implementazione,
+perché non è detto che si disponga di un numero di bit sufficienti per mettere
+tutti i segnali in un intero, o perché in \type{sigset\_t} possono essere
+immagazzinate ulteriori informazioni, tutte le operazioni devono essere
+effettuate tramite le opportune funzioni di libreria che si curano di
+mascherare i dettagli di basso livello.
+
+Lo standard POSIX.1 definisce cinque funzioni per la manipolazione degli
+insiemi di segnali. Le prime quattro, che consentono di manipolare i contenuti
+di un \textit{signal set}, sono \funcd{sigemptyset}, \funcd{sigfillset},
+\funcd{sigaddset} e \funcd{sigdelset}; i rispettivi prototipi sono:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigemptyset(sigset\_t *set)}
+\fdesc{Inizializza un insieme di segnali vuoto.}
+\fdecl{int sigfillset(sigset\_t *set)}
+\fdesc{Inizializza un insieme di segnali pieno.}
+\fdecl{int sigaddset(sigset\_t *set, int signum)}
+\fdesc{Aggiunge un segnale ad un insieme di segnali.}
+\fdecl{int sigdelset(sigset\_t *set, int signum)}
+\fdesc{Rimuove un segnale da un insieme di segnali.}
+}
+
+{Le funzioni ritornano $0$ in caso di successo, e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà il valore:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] \param{signum} non è un segnale valido.
+ \end{errlist}
+}
+\end{funcproto}
+
+Le prime due funzioni inizializzano l'insieme di segnali indicato
+dall'argomento \param{set} rispettivamente ad un contenuto vuoto (in cui cioè
+non c'è nessun segnale) e pieno (in cui cioè ci sono tutti i segnali). Le
+altre due funzioni consentono di inserire o rimuovere uno specifico segnale
+indicato con l'argomento \param{signum} in un insieme.
+
+A queste funzioni si aggiunge l'ulteriore \funcd{sigismember}, che consente di
+verificare la presenza di un segnale in un insieme, il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigismember(const sigset\_t *set, int signum)}
+\fdesc{Controlla se un segnale è in un insieme di segnali.}
+}
+
+{La funzione ritorna $1$ il segnale è nell'insieme e $0$ altrimenti, e $-1$
+ per un errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}
+ se si è specificato un puntatore \var{NULL}.}
+\end{funcproto}
+
+La \acr{glibc} prevede inoltre altre funzioni non standardizzate, accessibili
+definendo la macro \macro{\_GNU\_SOURCE}. La prima di queste è
+\funcd{sigisemptyset}, che consente di verificare un insieme è vuoto, il suo
+prototipo è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigisemptyset(sigset\_t *set)}
+\fdesc{Controlla se un insieme di segnali è vuoto.}
+}
+
+{La funzione ritorna $1$ l'insieme è vuoto e $0$ altrimenti, non sono previste
+ condizioni di errore.}
+\end{funcproto}
+
+Alla precedente si aggiungono altre due funzioni consentono di effettuare
+delle operazioni logiche con gli insiemi di segnali, esse sono
+\funcd{sigorset} e \funcd{sigandset}, ed i rispettivi prototipi sono:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{sigorset(sigset\_t *dest, sigset\_t *left, sigset\_t *right)}
+\fdesc{Crea l'unione di due insieme di segnali.}
+\fdecl{sigandset(sigset\_t *dest, sigset\_t *left, sigset\_t *right)}
+\fdesc{Crea l'intersezione di due insieme di segnali.}
+}
+
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà il valore \errcode{EINVAL}.}
+\end{funcproto}
+
+
+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 sez.~\ref{sec:sig_sigmask}). La modalità più comune, che
+è anche quella più portabile, prevede che possano essere definiti 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}.
+
+\itindend{signal~set}
+
+
+\subsection{La funzione \func{sigaction}}
+\label{sec:sig_sigaction}
+
+Abbiamo già accennato in sez.~\ref{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 principale funzione di sistema prevista dall'interfaccia POSIX.1 per la
+gestione dei segnali è \funcd{sigaction}. Essa ha sostanzialmente 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{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigaction(int signum, const struct sigaction *act, struct sigaction
+ *oldact)}
+\fdesc{Installa una nuova azione per un segnale.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
+ \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido o si è
+ cercato di installare il gestore per \signal{SIGKILL} o
+ \signal{SIGSTOP}.
+ \end{errlist}
+}
+\end{funcproto}
+
+La funzione serve ad installare una nuova \textsl{azione} per il segnale
+indicato dall'argomento \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 motivo lo standard POSIX.1 raccomanda di usare sempre questa
+funzione al posto della precedente \func{signal}, che in genere viene
+ridefinita in termini di \func{sigaction}, in quanto la nuova interfaccia
+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. Se
+sia \param{act} che \param{oldact} sono nulli la funzione può essere
+utilizzata per verificare che il segnale indicato sia valido per la
+piattaforma che si sta usando (se non lo è darà errore).
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/sigaction.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{sigaction}.}
+ \label{fig:sig_sigaction}
+\end{figure}
+
+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 fig.~\ref{fig:sig_sigaction}. Il campo
+\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
+più usato.
+
+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 la maschera dei segnali bloccati (vedi sez.~\ref{sec:sig_sigmask})
+viene comunque 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
+fig.~\ref{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 \signal{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
+tab.~\ref{tab:sig_sa_flag}.
+
+\begin{table}[!htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{SA\_NOCLDSTOP}& Se il segnale è \signal{SIGCHLD} allora non deve
+ essere notificato quando il processo figlio viene
+ fermato da uno dei segnali \signal{SIGSTOP},
+ \signal{SIGTSTP}, \signal{SIGTTIN} o
+ \signal{SIGTTOU}, questo flag ha significato solo
+ quando si imposta un gestore per \signal{SIGCHLD}.\\
+ \constd{SA\_NOCLDWAIT}& Se il segnale è \signal{SIGCHLD} e si richiede di
+ ignorare il segnale con \const{SIG\_IGN} allora i
+ processi figli non diventano \textit{zombie} quando
+ terminano; questa funzionalità è stata introdotta
+ nel kernel 2.6 e va a modificare il comportamento
+ di \func{waitpid} come illustrato in
+ sez.~\ref{sec:proc_wait}, se si installa un gestore
+ con questo flag attivo il segnale \signal{SIGCHLD}
+ viene comunque generato.\\
+ \constd{SA\_NODEFER} & Evita che il segnale corrente sia bloccato durante
+ l'esecuzione del gestore.\\
+ \constd{SA\_NOMASK} & Nome obsoleto e sinonimo non standard di
+ \const{SA\_NODEFER}, non deve essere più
+ utilizzato.\\
+ \constd{SA\_ONESHOT} & Nome obsoleto e sinonimo non standard di
+ \const{SA\_RESETHAND}, non deve essere più
+ utilizzato.\\
+ \constd{SA\_ONSTACK} & Stabilisce l'uso di uno \textit{stack} alternativo
+ per l'esecuzione del gestore (vedi
+ sez.~\ref{sec:sig_specific_features}).\\
+ \constd{SA\_RESETHAND}& Ristabilisce l'azione per il segnale al valore
+ predefinito una volta che il gestore è stato
+ lanciato, riproduce cioè il comportamento della
+ semantica inaffidabile.\\
+ \constd{SA\_RESTART} & Riavvia automaticamente le \textit{slow system
+ call} quando vengono interrotte dal suddetto
+ segnale, riproduce cioè il comportamento standard
+ di BSD.\\
+ \constd{SA\_RESTORER} & Ad uso delle implementazioni delle liberie del C,
+ non deve essere usato nelle applicazioni, serve ad
+ indicare che il campo \var{sa\_restorer} contiene
+ l'indirizzo di un cosiddetto \textit{signal
+ trampoline}.\footnotemark \\
+ \constd{SA\_SIGINFO} & Deve essere specificato quando si vuole usare un
+ gestore in forma estesa usando
+ \var{sa\_sigaction} al posto di
+ \var{sa\_handler}.\\
+ \hline
+ \end{tabular}
+ \caption{Valori del campo \var{sa\_flag} della struttura \struct{sigaction}.}
+ \label{tab:sig_sa_flag}
+\end{table}
+
+\footnotetext{il \itindex{signal~trampoline} \textit{signal trampoline} è il
+ codice usato per tornare da un gestore di segnali, che originariamente
+ veniva inserito nello \textit{stack}, ma i kernel recenti come misura di
+ sicurezza impediscono l'esecuzione di codice dallo stack, per cui questo
+ codice viene spostato altrove (ad esempio nella libreria del C) ed il suo
+ indirizzo viene indicato al kernel nel campo \var{sa\_restorer}.}
+
+Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette
+di utilizzare due forme diverse di gestore,\footnote{la possibilità è prevista
+ dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x
+ con l'introduzione dei segnali \textit{real-time} (vedi
+ sez.~\ref{sec:sig_real_time}); in precedenza era possibile ottenere alcune
+ informazioni addizionali usando \var{sa\_handler} con un secondo parametro
+ addizionale di tipo \var{sigcontext}, che adesso è deprecato.} da
+specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO},
+rispettivamente attraverso i campi \var{sa\_sigaction} o \var{sa\_handler}.
+Quest'ultima è quella classica usata anche con \func{signal}, mentre la prima
+permette di usare un gestore più complesso, in grado di ricevere informazioni
+più dettagliate dal sistema, attraverso la struttura \struct{siginfo\_t},
+riportata in fig.~\ref{fig:sig_siginfo_t}. I due campi devono essere usati in
+maniera alternativa, in certe implementazioni questi campi vengono addirittura
+definiti come una \direct{union}.\footnote{la direttiva \direct{union} del
+ linguaggio C definisce una variabile complessa, analoga a una stuttura, i
+ cui campi indicano i diversi tipi di valori che possono essere salvati, in
+ maniera alternativa, all'interno della stessa.}
+
+Installando un gestore di tipo \var{sa\_sigaction} diventa allora possibile
+accedere alle informazioni restituite attraverso il puntatore a questa
+struttura. Tutti i segnali impostano i campi \var{si\_signo}, che riporta il
+numero del segnale ricevuto, \var{si\_errno}, che riporta, quando diverso da
+zero, il codice dell'errore associato al segnale, e \var{si\_code}, che viene
+usato dal kernel per specificare maggiori dettagli riguardo l'evento che ha
+causato l'emissione del segnale.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.9\textwidth}
+ \includestruct{listati/siginfo_t.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{siginfo\_t}.}
+ \label{fig:sig_siginfo_t}
+\end{figure}
+
+In generale \var{si\_code} contiene, per i segnali generici, per quelli
+\textit{real-time} e per tutti quelli inviati tramite da un processo con
+\func{kill} o affini, le informazioni circa l'origine del segnale stesso, ad
+esempio se generato dal kernel, da un timer, da \func{kill}, ecc. Il valore
+viene sempre espresso come una costante,\footnote{le definizioni di tutti i
+ valori possibili si trovano in \file{bits/siginfo.h}.} ed i valori possibili
+in questo caso sono riportati in tab.~\ref{tab:sig_si_code_generic}.
+
+\begin{table}[!htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|p{10cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{SI\_USER} & Generato da \func{kill} o \func{raise} o affini.\\
+ \constd{SI\_KERNEL} & Inviato direttamente dal kernel.\\
+ \constd{SI\_QUEUE} & Inviato con \func{sigqueue} (vedi
+ sez.~\ref{sec:sig_real_time}).\\
+ \constd{SI\_TIMER} & Scadenza di un \textit{POSIX timer} (vedi
+ sez.~\ref{sec:sig_timer_adv}).\\
+ \constd{SI\_MESGQ} & Inviato al cambiamento di stato di una coda di
+ messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}),
+ introdotto con il kernel 2.6.6.\\
+ \constd{SI\_ASYNCIO}& Una operazione di I/O asincrono (vedi
+ sez.~\ref{sec:file_asyncronous_io}) è stata
+ completata.\\
+ \constd{SI\_SIGIO} & Segnale di \signal{SIGIO} da una coda (vedi
+ sez.~\ref{sec:file_asyncronous_operation}).\\
+ \constd{SI\_TKILL} & Inviato da \func{tkill} o \func{tgkill} (vedi
+ sez.~\ref{cha:thread_xxx}), introdotto con il kernel
+ 2.4.19.\\
+ \hline
+ \end{tabular}
+ \caption{Valori del campo \var{si\_code} della struttura \struct{sigaction}
+ per i segnali generici.}
+ \label{tab:sig_si_code_generic}
+\end{table}
+
+Nel caso di alcuni segnali però il valore di \var{si\_code} viene usato per
+fornire una informazione specifica relativa alle motivazioni della ricezione
+dello stesso; ad esempio i vari segnali di errore (\signal{SIGILL},
+\signal{SIGFPE}, \signal{SIGSEGV} e \signal{SIGBUS}) lo usano per fornire
+maggiori dettagli riguardo l'errore, come il tipo di errore aritmetico, di
+istruzione illecita o di violazione di memoria; mentre alcuni segnali di
+controllo (\signal{SIGCHLD}, \signal{SIGTRAP} e \signal{SIGPOLL}) forniscono
+altre informazioni specifiche.
+
+
+In questo caso il valore del campo \var{si\_code} deve essere verificato nei
+confronti delle diverse costanti previste per ciascuno di detti segnali; dato
+che si tratta di costanti, e non di una maschera binaria, i valori numerici
+vengono riutilizzati e ciascuno di essi avrà un significato diverso a seconda
+del segnale a cui è associato.
+
+L'elenco dettagliato dei nomi di queste costanti è riportato nelle diverse
+sezioni di tab.~\ref{tab:sig_si_code_special} che sono state ordinate nella
+sequenza in cui si sono appena citati i rispettivi segnali, il prefisso del
+nome indica comunque in maniera diretta il segnale a cui le costanti fanno
+riferimento.
+
+\begin{table}[!htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{ILL\_ILLOPC} & Codice di operazione illegale.\\
+ \constd{ILL\_ILLOPN} & Operando illegale.\\
+ \constd{ILL\_ILLADR} & Modo di indirizzamento illegale.\\
+ \constd{ILL\_ILLTRP} & Trappola di processore illegale.\\
+ \constd{ILL\_PRVOPC} & Codice di operazione privilegiato.\\
+ \constd{ILL\_PRVREG} & Registro privilegiato.\\
+ \constd{ILL\_COPROC} & Errore del coprocessore.\\
+ \constd{ILL\_BADSTK} & Errore nello stack interno.\\
+ \hline
+ \constd{FPE\_INTDIV} & Divisione per zero intera.\\
+ \constd{FPE\_INTOVF} & Overflow intero.\\
+ \constd{FPE\_FLTDIV} & Divisione per zero in virgola mobile.\\
+ \constd{FPE\_FLTOVF} & Overflow in virgola mobile.\\
+ \constd{FPE\_FLTUND} & Underflow in virgola mobile.\\
+ \constd{FPE\_FLTRES} & Risultato in virgola mobile non esatto.\\
+ \constd{FPE\_FLTINV} & Operazione in virgola mobile non valida.\\
+ \constd{FPE\_FLTSUB} & Mantissa? fuori intervallo.\\
+ \hline
+ \constd{SEGV\_MAPERR} & Indirizzo non mappato.\\
+ \constd{SEGV\_ACCERR} & Permessi non validi per l'indirizzo.\\
+ \hline
+ \constd{BUS\_ADRALN} & Allineamento dell'indirizzo non valido.\\
+ \constd{BUS\_ADRERR} & Indirizzo fisico inesistente.\\
+ \constd{BUS\_OBJERR} & Errore hardware sull'indirizzo.\\
+ \hline
+ \constd{TRAP\_BRKPT} & Breakpoint sul processo.\\
+ \constd{TRAP\_TRACE} & Trappola di tracciamento del processo.\\
+ \hline
+ \constd{CLD\_EXITED} & Il figlio è uscito.\\
+ \constd{CLD\_KILLED} & Il figlio è stato terminato.\\
+ \constd{CLD\_DUMPED} & Il figlio è terminato in modo anormale.\\
+ \constd{CLD\_TRAPPED} & Un figlio tracciato ha raggiunto una trappola.\\
+ \constd{CLD\_STOPPED} & Il figlio è stato fermato.\\
+ \constd{CLD\_CONTINUED}& Il figlio è ripartito.\\
+ \hline
+ \constd{POLL\_IN} & Disponibili dati in ingresso.\\
+ \constd{POLL\_OUT} & Spazio disponibile sul buffer di uscita.\\
+ \constd{POLL\_MSG} & Disponibili messaggi in ingresso.\\
+ \constd{POLL\_ERR} & Errore di I/O.\\
+ \constd{POLL\_PRI} & Disponibili dati di alta priorità in ingresso.\\
+ \constd{POLL\_HUP} & Il dispositivo è stato disconnesso.\\
+ \hline
+ \end{tabular}
+ \caption{Valori del campo \var{si\_code} della struttura \struct{sigaction}
+ impostati rispettivamente dai segnali \signal{SIGILL}, \signal{SIGFPE},
+ \signal{SIGSEGV}, \signal{SIGBUS}, \signal{SIGCHLD}, \signal{SIGTRAP} e
+ \signal{SIGPOLL}/\signal{SIGIO}.}
+ \label{tab:sig_si_code_special}
+\end{table}
+
+Il resto della struttura \struct{siginfo\_t} è definito come una \dirct{union}
+ed i valori eventualmente presenti dipendono dal segnale ricevuto, così
+\signal{SIGCHLD} ed i segnali \textit{real-time} (vedi
+sez.~\ref{sec:sig_real_time}) inviati tramite \func{kill} avvalorano
+\var{si\_pid} e \var{si\_uid} coi valori corrispondenti al processo che ha
+emesso il segnale, \signal{SIGCHLD} avvalora anche i campi \var{si\_status},
+\var{si\_utime} e \var{si\_stime} che indicano rispettivamente lo stato di
+uscita, l'\textit{user time} e il \textit{system time} (vedi
+sez.~\ref{sec:sys_cpu_times}) usati dal processo; \signal{SIGILL},
+\signal{SIGFPE}, \signal{SIGSEGV} e \signal{SIGBUS} avvalorano \var{si\_addr}
+con l'indirizzo in cui è avvenuto l'errore, \signal{SIGIO} (vedi
+sez.~\ref{sec:file_asyncronous_io}) avvalora \var{si\_fd} con il numero del
+file descriptor e \var{si\_band} per i dati urgenti (vedi
+sez.~\ref{sec:TCP_urgent_data}) su un socket, il segnale inviato alla scadenza
+di un POSIX timer (vedi sez.~\ref{sec:sig_timer_adv}) avvalora i campi
+\var{si\_timerid} e \var{si\_overrun}.
+
+Benché sia possibile usare nello stesso programma sia \func{sigaction} che
+\func{signal} occorre molta attenzione, in quanto le due funzioni possono
+interagire in maniera anomala. Infatti l'azione specificata con
+\struct{sigaction} contiene un maggior numero di informazioni rispetto al
+semplice indirizzo del gestore restituito da \func{signal}. Per questo motivo
+se si usa quest'ultima per installare un gestore sostituendone uno
+precedentemente installato con \func{sigaction}, non sarà possibile effettuare
+un ripristino corretto dello stesso.
+
+Per questo è sempre opportuno usare \func{sigaction}, che è in grado di
+ripristinare correttamente un gestore precedente, anche se questo è stato
+installato con \func{signal}. In generale poi non è il caso di usare il valore
+di ritorno di \func{signal} come campo \var{sa\_handler}, o viceversa, dato
+che in certi sistemi questi possono essere diversi. In definitiva dunque, a
+meno che non si sia vincolati all'aderenza stretta allo standard ISO C, è
+sempre il caso di evitare l'uso di \func{signal} a favore di \func{sigaction}.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/Signal.c}
+ \end{minipage}
+ \normalsize
+ \caption{La funzione \func{Signal}, equivalente a \func{signal}, definita
+ attraverso \func{sigaction}.}
+ \label{fig:sig_Signal_code}
+\end{figure}
+
+Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
+che abbia le stesse caratteristiche di \func{signal}, a definire attraverso
+\func{sigaction} una funzione equivalente \func{Signal}, il cui codice è
+riportato in fig.~\ref{fig:sig_Signal_code} (il codice completo si trova nel
+file \file{SigHand.c} nei sorgenti allegati). Anche in questo caso, per
+semplificare la definizione si è poi definito un apposito tipo
+\texttt{SigFunc} per esprimere in modo più comprensibile la forma di un
+gestore di segnale.
+
+Si noti come, essendo la funzione estremamente semplice, essa è definita come
+\dirct{inline}. Questa direttiva viene usata per dire al compilatore di
+trattare la funzione cui essa fa riferimento in maniera speciale inserendo il
+codice direttamente nel testo del programma. Anche se i compilatori più
+moderni sono in grado di effettuare da soli queste manipolazioni (impostando
+le opportune ottimizzazioni) questa è una tecnica usata per migliorare le
+prestazioni per le funzioni piccole ed usate di frequente, in particolare nel
+kernel, dove in certi casi le ottimizzazioni dal compilatore, tarate per l'uso
+in \textit{user space}, non sono sempre adatte.
+
+In tal caso infatti le istruzioni per creare un nuovo frame nello
+\textit{stack} per chiamare la funzione costituirebbero una parte rilevante
+del codice, appesantendo inutilmente il programma. Originariamente questo
+comportamento veniva ottenuto con delle macro, ma queste hanno tutta una serie
+di problemi di sintassi nel passaggio degli argomenti (si veda ad esempio
+\cite{PratC}) che in questo modo possono essere evitati.
+
+
+
+\subsection{La gestione della \textsl{maschera dei segnali} o
+ \textit{signal mask}}
+\label{sec:sig_sigmask}
+
+\index{maschera dei segnali|(}
+
+Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi
+unix-like permettono di bloccare temporaneamente (o di eliminare
+completamente, impostando come azione \const{SIG\_IGN}) la consegna dei
+segnali ad un processo. Questo è fatto specificando la cosiddetta
+\textsl{maschera dei segnali} (o \textit{signal mask}) del
+processo\footnote{nel caso di Linux essa è mantenuta dal campo \var{blocked}
+ della \struct{task\_struct} del processo.} cioè l'insieme dei segnali la cui
+consegna è bloccata.
+
+Abbiamo accennato in sez.~\ref{sec:proc_fork} che la maschera dei segnali
+viene ereditata dal padre alla creazione di un processo figlio, e abbiamo
+visto al paragrafo precedente che essa può essere modificata durante
+l'esecuzione di un gestore ed automaticamente ripristinata quando questo
+ritorna, attraverso l'uso dal campo \var{sa\_mask} di \struct{sigaction}.
+
+Uno dei problemi evidenziatisi con l'esempio di fig.~\ref{fig:sig_event_wrong}
+è che in molti casi è necessario proteggere delle sezioni di codice, in modo
+da essere sicuri che essi siano eseguite senza interruzioni da parte di un
+segnale. Nel caso in questione si trattava della sezione di codice fra il
+controllo e la eventuale cancellazione del flag impostato dal gestore di un
+segnale che testimoniava l'avvenuta occorrenza dello stesso.
+
+Come illustrato in sez.~\ref{sec:proc_atom_oper} le operazioni più semplici,
+come l'assegnazione o il controllo di una variabile, di norma sono atomiche, e
+qualora si voglia essere sicuri si può usare il tipo \type{sig\_atomic\_t}. Ma
+quando si devono eseguire più operazioni su delle variabili (nell'esempio
+citato un controllo ed una assegnazione) o comunque eseguire una serie di
+istruzioni, l'atomicità non è più possibile.
+
+In questo caso, se si vuole essere sicuri di non poter essere interrotti da un
+segnale durante l'esecuzione di una sezione di codice, lo si può bloccare
+esplicitamente modificando la maschera dei segnali del processo con la
+funzione di sistema \funcd{sigprocmask}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigprocmask(int how, const sigset\_t *set, sigset\_t *oldset)}
+\fdesc{Imposta la maschera dei segnali del processo corrente.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
+ \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
+ \end{errlist}
+}
+\end{funcproto}
+
+La funzione usa l'insieme di segnali posto all'indirizzo passato
+nell'argomento \param{set} per modificare la maschera dei segnali del processo
+corrente. La modifica viene effettuata a seconda del valore
+dell'argomento \param{how}, secondo le modalità specificate in
+tab.~\ref{tab:sig_procmask_how}. Qualora si specifichi un valore non nullo
+per \param{oldset} la maschera dei segnali corrente viene salvata a
+quell'indirizzo.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{SIG\_BLOCK} & L'insieme dei segnali bloccati è l'unione fra
+ quello specificato e quello corrente.\\
+ \constd{SIG\_UNBLOCK} & I segnali specificati in \param{set} sono rimossi
+ dalla maschera dei segnali, specificare la
+ cancellazione di un segnale non bloccato è legale.\\
+ \constd{SIG\_SETMASK} & La maschera dei segnali è impostata al valore
+ specificato da \param{set}.\\
+ \hline
+ \end{tabular}
+ \caption{Valori e significato dell'argomento \param{how} della funzione
+ \func{sigprocmask}.}
+ \label{tab:sig_procmask_how}
+\end{table}
+
+In questo modo diventa possibile proteggere delle sezioni di codice bloccando
+l'insieme di segnali voluto per poi riabilitarli alla fine della sezione
+critica. La funzione permette di risolvere problemi come quelli mostrati in
+fig.~\ref{fig:sig_event_wrong}, proteggendo la sezione fra il controllo del
+flag e la sua cancellazione. La funzione può essere usata anche all'interno
+di un gestore, ad esempio per riabilitare la consegna del segnale che l'ha
+invocato, in questo caso però occorre ricordare che qualunque modifica alla
+maschera dei segnali viene perduta al ritorno dallo stesso.
+
+Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
+dei casi di \textit{race condition} restano aperte alcune possibilità legate
+all'uso di \func{pause}. Il caso è simile a quello del problema illustrato
+nell'esempio di fig.~\ref{fig:sig_sleep_incomplete}, e cioè la possibilità che
+il processo riceva il segnale che si intende usare per uscire dallo stato di
+attesa invocato con \func{pause} immediatamente prima dell'esecuzione di
+quest'ultima. Per poter effettuare atomicamente la modifica della maschera dei
+segnali (di solito attivandone uno specifico) insieme alla sospensione del
+processo lo standard POSIX ha previsto la funzione di sistema
+\funcd{sigsuspend}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigsuspend(const sigset\_t *mask)}
+\fdesc{Imposta la maschera dei segnali mettendo in attesa il processo.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
+ \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
+ \end{errlist}
+}
+\end{funcproto}
+
+Come esempio dell'uso di queste funzioni proviamo a riscrivere un'altra volta
+l'esempio di implementazione di \code{sleep}. Abbiamo accennato in
+sez.~\ref{sec:sig_sigaction} come con \func{sigaction} sia possibile bloccare
+\signal{SIGALRM} nell'installazione dei gestori degli altri segnali, per poter
+usare l'implementazione vista in fig.~\ref{fig:sig_sleep_incomplete} senza
+interferenze. Questo però comporta una precauzione ulteriore al semplice uso
+della funzione, vediamo allora come usando la nuova interfaccia è possibile
+ottenere un'implementazione, riportata in fig.~\ref{fig:sig_sleep_ok} che non
+presenta neanche questa necessità.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/sleep.c}
+ \end{minipage}
+ \normalsize
+ \caption{Una implementazione completa di \func{sleep}.}
+ \label{fig:sig_sleep_ok}
+\end{figure}
+
+Per evitare i problemi di interferenza con gli altri segnali in questo caso
+non si è usato l'approccio di fig.~\ref{fig:sig_sleep_incomplete} evitando
+l'uso di \func{longjmp}. Come in precedenza il gestore (\texttt{\small
+ 27--30}) non esegue nessuna operazione, limitandosi a ritornare per
+interrompere il programma messo in attesa.
+
+La prima parte della funzione (\texttt{\small 6--10}) provvede ad installare
+l'opportuno gestore per \signal{SIGALRM}, salvando quello originario, che
+sarà ripristinato alla conclusione della stessa (\texttt{\small 23}); il passo
+successivo è quello di bloccare \signal{SIGALRM} (\texttt{\small 11--14}) per
+evitare che esso possa essere ricevuto dal processo fra l'esecuzione di
+\func{alarm} (\texttt{\small 16}) e la sospensione dello stesso. Nel fare
+questo si salva la maschera corrente dei segnali, che sarà ripristinata alla
+fine (\texttt{\small 22}), e al contempo si prepara la maschera dei segnali
+\var{sleep\_mask} per riattivare \signal{SIGALRM} all'esecuzione di
+\func{sigsuspend}.
+
+In questo modo non sono più possibili \textit{race condition} dato che
+\signal{SIGALRM} viene disabilitato con \func{sigprocmask} fino alla chiamata
+di \func{sigsuspend}. Questo metodo è assolutamente generale e può essere
+applicato a qualunque altra situazione in cui si deve attendere per un
+segnale, i passi sono sempre i seguenti:
+\begin{enumerate*}
+\item leggere la maschera dei segnali corrente e bloccare il segnale voluto
+ con \func{sigprocmask};
+\item mandare il processo in attesa con \func{sigsuspend} abilitando la
+ ricezione del segnale voluto;
+\item ripristinare la maschera dei segnali originaria.
+\end{enumerate*}
+Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi
+riabilitarla immediatamente dopo, in questo modo si evita il \textit{deadlock}
+dovuto all'arrivo del segnale prima dell'esecuzione di \func{sigsuspend}.
+
+\index{maschera dei segnali|)}
+
+
+\subsection{Criteri di programmazione per i gestori dei segnali}
+\label{sec:sig_signal_handler}
+
+Abbiamo finora parlato dei gestori dei segnali come funzioni chiamate in
+corrispondenza della consegna di un segnale. In realtà un gestore non può
+essere una funzione qualunque, in quanto esso può essere eseguito in
+corrispondenza all'interruzione in un punto qualunque del programma
+principale, cosa che ad esempio può rendere problematico chiamare all'interno
+di un gestore di segnali la stessa funzione che dal segnale è stata
+interrotta.
+
+\index{funzioni!\textit{signal safe}|(}
+
+Il concetto è comunque più generale e porta ad una distinzione fra quelle che
+POSIX chiama \textsl{funzioni insicure} (\textit{signal unsafe function}) e
+\textsl{funzioni sicure} (o più precisamente \textit{signal safe function}).
+Quando un segnale interrompe una funzione insicura ed il gestore chiama al suo
+interno una funzione insicura il sistema può dare luogo ad un comportamento
+indefinito, la cosa non avviene invece per le funzioni sicure.
+
+Tutto questo significa che la funzione che si usa come gestore di segnale deve
+essere programmata con molta cura per evirare questa evenienza e che non è
+possibile utilizzare al suo interno una qualunque funzione di sistema, se si
+vogliono evitare questi problemi si può ricorrere soltanto all'uso delle
+funzioni considerate sicure.
+
+L'elenco delle funzioni considerate sicure varia a seconda della
+implementazione utilizzata e dello standard a cui si fa riferimento. Non è
+riportata una lista specifica delle funzioni sicure per Linux, e si suppone
+pertanto che siano quelle richieste dallo standard. Secondo quanto richiesto
+dallo standard POSIX 1003.1 nella revisione del 2003, le ``\textit{signal safe
+ function}'' che possono essere chiamate anche all'interno di un gestore di
+segnali sono tutte quelle della lista riportata in
+fig.~\ref{fig:sig_safe_functions}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{14cm}
+ \func{\_exit}, \func{abort}, \func{accept}, \func{access},
+ \func{aio\_error} \func{aio\_return}, \func{aio\_suspend}, \func{alarm},
+ \func{bind}, \func{cfgetispeed}, \func{cfgetospeed}, \func{cfsetispeed},
+ \func{cfsetospeed}, \func{chdir}, \func{chmod}, \func{chown},
+ \func{clock\_gettime}, \func{close}, \func{connect}, \func{creat},
+ \func{dup}, \func{dup2}, \func{execle}, \func{execve}, \func{fchmod},
+ \func{fchown}, \func{fcntl}, \func{fdatasync}, \func{fork},
+ \func{fpathconf}, \func{fstat}, \func{fsync}, \func{ftruncate},
+ \func{getegid}, \func{geteuid}, \func{getgid}, \func{getgroups},
+ \func{getpeername}, \func{getpgrp}, \func{getpid}, \func{getppid},
+ \func{getsockname}, \func{getsockopt}, \func{getuid}, \func{kill},
+ \func{link}, \func{listen}, \func{lseek}, \func{lstat}, \func{mkdir},
+ \func{mkfifo}, \func{open}, \func{pathconf}, \func{pause}, \func{pipe},
+ \func{poll}, \funcm{posix\_trace\_event}, \func{pselect}, \func{raise},
+ \func{read}, \func{readlink}, \func{recv}, \func{recvfrom},
+ \func{recvmsg}, \func{rename}, \func{rmdir}, \func{select},
+ \func{sem\_post}, \func{send}, \func{sendmsg}, \func{sendto},
+ \func{setgid}, \func{setpgid}, \func{setsid}, \func{setsockopt},
+ \func{setuid}, \func{shutdown}, \func{sigaction}, \func{sigaddset},
+ \func{sigdelset}, \func{sigemptyset}, \func{sigfillset},
+ \func{sigismember}, \func{signal}, \func{sigpause}, \func{sigpending},
+ \func{sigprocmask}, \func{sigqueue}, \funcm{sigset}, \func{sigsuspend},
+ \func{sleep}, \func{socket}, \func{socketpair}, \func{stat},
+ \func{symlink}, \func{sysconf}, \func{tcdrain}, \func{tcflow},
+ \func{tcflush}, \func{tcgetattr}, \func{tcgetgrp}, \func{tcsendbreak},
+ \func{tcsetattr}, \func{tcsetpgrp}, \func{time}, \func{timer\_getoverrun},
+ \func{timer\_gettime}, \func{timer\_settime}, \func{times}, \func{umask},
+ \func{uname}, \func{unlink}, \func{utime}, \func{wait}, \func{waitpid},
+ \func{write}.
+ \end{minipage}
+ \normalsize
+ \caption{Elenco delle funzioni sicure secondo lo standard POSIX
+ 1003.1-2003.}
+ \label{fig:sig_safe_functions}
+\end{figure}
+
+\index{funzioni!\textit{signal safe}|)}
+
+Lo standard POSIX.1-2004 modifica la lista di
+fig.~\ref{fig:sig_safe_functions} aggiungendo le funzioni \func{\_Exit} e
+\func{sockatmark}, mentre lo standard POSIX.1-2008 rimuove della lista le tre
+funzioni \func{fpathconf}, \func{pathconf}, \func{sysconf} e vi aggiunge le
+ulteriori funzioni in fig.~\ref{fig:sig_safe_functions_posix_2008}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{14cm}
+ \func{execl}, \func{execv}, \func{faccessat}, \func{fchmodat},
+ \func{fchownat}, \func{fexecve}, \func{fstatat}, \func{futimens},
+ \func{linkat}, \func{mkdirat}, \func{mkfifoat}, \func{mknod},
+ \func{mknodat}, \func{openat}, \func{readlinkat}, \func{renameat},
+ \func{symlinkat}, \func{unlinkat}, \func{utimensat}, \func{utimes}.
+ \end{minipage}
+ \normalsize
+ \caption{Ulteriori funzioni sicure secondo lo standard POSIX.1-2008.}
+ \label{fig:sig_safe_functions_posix_2008}
+\end{figure}
+
+
+Per questo motivo è opportuno mantenere al minimo indispensabile le operazioni
+effettuate all'interno di un gestore di segnali, qualora si debbano compiere
+operazioni complesse è sempre preferibile utilizzare la tecnica in cui si usa
+il gestore per impostare il valore di una qualche variabile globale, e poi si
+eseguono le operazioni complesse nel programma verificando (con tutti gli
+accorgimenti visti in precedenza) il valore di questa variabile tutte le volte
+che si è rilevata una interruzione dovuta ad un segnale.
+
+
+\section{Funzionalità avanzate}
+\label{sec:sig_advanced_signal}
+
+Tratteremo in questa ultima sezione alcune funzionalità avanzate relativa ai
+segnali ed in generale ai meccanismi di notifica, a partire dalla funzioni
+introdotte per la gestione dei cosiddetti ``\textsl{segnali real-time}'', alla
+gestione avanzata delle temporizzazioni e le nuove interfacce per la gestione
+di segnali ed eventi attraverso l'uso di file descriptor.
+
+\subsection{I segnali \textit{real-time}}
+\label{sec:sig_real_time}
+
+Lo standard POSIX.1b, nel definire una serie di nuove interfacce per i servizi
+\textit{real-time}, ha introdotto una estensione del modello classico dei
+segnali che presenta dei significativi miglioramenti,\footnote{questa
+ estensione è stata introdotta in Linux a partire dal kernel 2.1.43, e dalla
+ versione 2.1 della \acr{glibc}.} in particolare sono stati superati tre
+limiti fondamentali dei segnali classici:
+\begin{basedescript}{\desclabelwidth{1cm}\desclabelstyle{\nextlinelabel}}
+\item[\textbf{I segnali non sono accumulati}]
+ se più segnali vengono generati prima dell'esecuzione di un gestore
+ questo sarà eseguito una sola volta, ed il processo non sarà in grado di
+ accorgersi di quante volte l'evento che ha generato il segnale è accaduto.
+\item[\textbf{I segnali non trasportano informazione}]
+ i segnali classici non prevedono altra informazione sull'evento
+ che li ha generati se non il fatto che sono stati emessi (tutta
+ l'informazione che il kernel associa ad un segnale è il suo numero).
+\item[\textbf{I segnali non hanno un ordine di consegna}]
+ l'ordine in cui diversi segnali vengono consegnati è casuale e non
+ prevedibile. Non è possibile stabilire una priorità per cui la reazione a
+ certi segnali ha la precedenza rispetto ad altri.
+\end{basedescript}
+
+Per poter superare queste limitazioni lo standard POSIX.1b ha introdotto delle
+nuove caratteristiche, che sono state associate ad una nuova classe di
+segnali, che vengono chiamati \textsl{segnali real-time}, in particolare le
+funzionalità aggiunte sono:
+
+\begin{enumerate}
+\item i segnali sono inseriti in una coda che permette di consegnare istanze
+ multiple dello stesso segnale qualora esso venga inviato più volte prima
+ dell'esecuzione del gestore; si assicura così che il processo riceva un
+ segnale per ogni occorrenza dell'evento che lo genera;
+\item è stata introdotta una priorità nella consegna dei segnali: i segnali
+ vengono consegnati in ordine a seconda del loro valore, partendo da quelli
+ con un numero minore, che pertanto hanno una priorità maggiore;
+\item è stata introdotta la possibilità di restituire dei dati al gestore,
+ attraverso l'uso di un apposito campo \var{si\_value} nella struttura
+ \struct{siginfo\_t}, accessibile tramite gestori di tipo
+ \var{sa\_sigaction}.
+\end{enumerate}
+
+Tutte queste nuove funzionalità eccetto l'ultima, che, come illustrato in
+sez.~\ref{sec:sig_sigaction}, è disponibile anche con i segnali ordinari, si
+applicano solo ai nuovi segnali \textit{real-time}; questi ultimi sono
+accessibili in un intervallo di valori specificati dalle due costanti
+\constd{SIGRTMIN} e \constd{SIGRTMAX}, che specificano il numero minimo e
+massimo associato ad un segnale \textit{real-time}.
+
+Su Linux di solito il primo valore è 33, mentre il secondo è \code{\_NSIG-1},
+che di norma (vale a dire sulla piattaforma i386) è 64. Questo dà un totale di
+32 segnali disponibili, contro gli almeno 8 richiesti da POSIX.1b. Si tenga
+presente però che i primi segnali \textit{real-time} disponibili vengono usati
+dalla \acr{glibc} per l'implementazione dei \textit{thread} POSIX (vedi
+sez.~\ref{sec:thread_posix_intro}), ed il valore di \const{SIGRTMIN} viene
+modificato di conseguenza.\footnote{per la precisione vengono usati i primi
+ tre per la vecchia implementazione dei \textit{LinuxThread} ed i primi due
+ per la nuova NTPL (\textit{New Thread Posix Library}), il che comporta che
+ \const{SIGRTMIN} a seconda dei casi può assumere i valori 34 o 35.}
+
+Per questo motivo nei programmi che usano i segnali \textit{real-time} non si
+deve mai usare un valore assoluto dato che si correrebbe il rischio di
+utilizzare un segnale in uso alle librerie, ed il numero del segnale deve
+invece essere sempre specificato in forma relativa a \const{SIGRTMIN} (come
+\code{SIGRTMIN + n}) avendo inoltre cura di controllare di non aver mai
+superato \const{SIGRTMAX}.
+
+I segnali con un numero più basso hanno una priorità maggiore e vengono
+consegnati per primi, inoltre i segnali \textit{real-time} non possono
+interrompere l'esecuzione di un gestore di un segnale a priorità più alta; la
+loro azione predefinita è quella di terminare il programma. I segnali
+ordinari hanno tutti la stessa priorità, che è più alta di quella di qualunque
+segnale \textit{real-time}. Lo standard non definisce niente al riguardo ma
+Linux, come molte altre implementazioni, adotta questa politica.
+
+Si tenga presente che questi nuovi segnali non sono associati a nessun evento
+specifico, a meno di non richiedere specificamente il loro utilizzo in
+meccanismi di notifica come quelli per l'I/O asincrono (vedi
+sez.~\ref{sec:file_asyncronous_io}) o per le code di messaggi POSIX (vedi
+sez.~\ref{sec:ipc_posix_mq}), pertanto devono essere inviati esplicitamente.
+
+Inoltre, per poter usufruire della capacità di restituire dei dati, i relativi
+gestori devono essere installati con \func{sigaction}, specificando per
+\var{sa\_flags} la modalità \const{SA\_SIGINFO} che permette di utilizzare la
+forma estesa \var{sa\_sigaction} del gestore (vedi
+sez.~\ref{sec:sig_sigaction}). In questo modo tutti i segnali
+\textit{real-time} possono restituire al gestore una serie di informazioni
+aggiuntive attraverso l'argomento \struct{siginfo\_t}, la cui definizione è
+stata già vista in fig.~\ref{fig:sig_siginfo_t}, nella trattazione dei gestori
+in forma estesa.
+
+In particolare i campi utilizzati dai segnali \textit{real-time} sono
+\var{si\_pid} e \var{si\_uid} in cui vengono memorizzati rispettivamente il
+\ids{PID} e l'\ids{UID} effettivo del processo che ha inviato il segnale,
+mentre per la restituzione dei dati viene usato il campo \var{si\_value}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/sigval_t.h}
+ \end{minipage}
+ \normalsize
+ \caption{La definizione dell'unione \structd{sigval}, definita anche come
+ tipo \typed{sigval\_t}.}
+ \label{fig:sig_sigval}
+\end{figure}
+
+Detto campo, identificato con il tipo di dato \type{sigval\_t}, è una
+\dirct{union} di tipo \struct{sigval} (la sua definizione è in
+fig.~\ref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico,
+se usata nella forma \var{sival\_int}, o un puntatore, se usata nella forma
+\var{sival\_ptr}. L'unione viene usata dai segnali \textit{real-time} e da
+vari meccanismi di notifica per restituire dati al gestore del segnale in
+\var{si\_value}. Un campo di tipo \type{sigval\_t} è presente anche nella
+struttura \struct{sigevent} (definita in fig.~\ref{fig:struct_sigevent}) che
+viene usata dai meccanismi di notifica come quelli per i timer POSIX (vedi
+sez.~\ref{sec:sig_timer_adv}), l'I/O asincrono (vedi
+sez.~\ref{sec:file_asyncronous_io}) o le code di messaggi POSIX (vedi
+sez.~\ref{sec:ipc_posix_mq}).
+
+A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
+inviare segnali \textit{real-time}, poiché non è in grado di fornire alcun
+valore per il campo \var{si\_value} restituito nella struttura
+\struct{siginfo\_t} prevista da un gestore in forma estesa. Per questo motivo
+lo standard ha previsto una nuova funzione, \funcd{sigqueue}, il cui prototipo
+è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigqueue(pid\_t pid, int signo, const union sigval value)}
+\fdesc{Invia un segnale con un valore di informazione.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EAGAIN}] la coda è esaurita, ci sono già
+ \const{SIGQUEUE\_MAX} segnali in attesa si consegna.
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per
+ \param{signo}.
+ \item[\errcode{EPERM}] non si hanno privilegi appropriati per inviare il
+ segnale al processo specificato.
+ \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
+ \end{errlist}
+}
+\end{funcproto}
+
+
+La funzione invia il segnale indicato dall'argomento \param{signo} al processo
+indicato dall'argomento \param{pid}. Per il resto il comportamento della
+funzione è analogo a quello di \func{kill}, ed i privilegi occorrenti ad
+inviare il segnale ad un determinato processo sono gli stessi; un valore nullo
+di \param{signo} permette di verificare le condizioni di errore senza inviare
+nessun segnale.
+
+Se il segnale è bloccato la funzione ritorna immediatamente, se si è
+installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili,
+(vale a dire che c'è posto nella coda dei segnali \textit{real-time}) esso
+viene inserito e diventa pendente. Una volta consegnato il segnale il gestore
+otterrà nel campo \var{si\_code} di \struct{siginfo\_t} il valore
+\const{SI\_QUEUE} e nel campo \var{si\_value} il valore indicato
+nell'argomento \param{value}. Se invece si è installato un gestore nella forma
+classica il segnale sarà generato, ma tutte le caratteristiche tipiche dei
+segnali \textit{real-time} (priorità e coda) saranno perse.
+
+Per lo standard POSIX la profondità della coda è indicata dalla costante
+\constd{SIGQUEUE\_MAX}, una della tante costanti di sistema definite dallo
+standard POSIX che non abbiamo riportato esplicitamente in
+sez.~\ref{sec:sys_limits}. Il suo valore minimo secondo lo standard,
+\macrod{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux la coda ha una
+dimensione variabile; fino alla versione 2.6.7 c'era un limite massimo globale
+che poteva essere impostato come parametro del kernel in
+\sysctlfiled{kernel/rtsig-max} ed il valore predefinito era pari a 1024. A
+partire dal kernel 2.6.8 il valore globale è stato rimosso e sostituito dalla
+risorsa \const{RLIMIT\_SIGPENDING} associata al singolo utente, che può essere
+modificata con \func{setrlimit} come illustrato in
+sez.~\ref{sec:sys_resource_limit}.
+
+Lo standard POSIX.1b definisce inoltre delle nuove funzioni di sistema che
+permettono di gestire l'attesa di segnali specifici su una coda, esse servono
+in particolar modo nel caso dei \textit{thread}, in cui si possono usare i
+segnali \textit{real-time} come meccanismi di comunicazione elementare; la
+prima di queste è \funcd{sigwait}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigwait(const sigset\_t *set, int *sig)}
+\fdesc{Attende la ricezione di un segnale.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINTR}] la funzione è stata interrotta.
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per
+ \end{errlist}
+ ed inoltre \errval{EFAULT} nel suo significato generico.}
+\end{funcproto}
+
+La funzione estrae dall'insieme dei segnali pendenti uno qualunque fra quelli
+indicati nel \textit{signal set} specificato in \param{set}, il cui valore
+viene restituito nella variabile puntata da \param{sig}. Se sono pendenti più
+segnali, viene estratto quello a priorità più alta, cioè quello con il numero
+più basso. Se, nel caso di segnali \textit{real-time}, c'è più di un segnale
+pendente, ne verrà estratto solo uno. Una volta estratto il segnale non verrà
+più consegnato, e se era in una coda il suo posto sarà liberato. Se non c'è
+nessun segnale pendente il processo viene bloccato fintanto che non ne arriva
+uno.
+
+Per un funzionamento corretto la funzione richiede che alla sua chiamata i
+segnali di \param{set} siano bloccati. In caso contrario si avrebbe un
+conflitto con gli eventuali gestori: pertanto non si deve utilizzare per
+lo stesso segnale questa funzione e \func{sigaction}. Se questo non avviene il
+comportamento del sistema è indeterminato: il segnale può sia essere
+consegnato che essere ricevuto da \func{sigwait}, il tutto in maniera non
+prevedibile.
+
+Lo standard POSIX.1b definisce altre due funzioni di sistema, anch'esse usate
+prevalentemente con i \textit{thread}; \funcd{sigwaitinfo} e
+\funcd{sigtimedwait}, i relativi prototipi sono:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigwaitinfo(const sigset\_t *set, siginfo\_t *info)}
+\fdesc{Attende un segnale con le relative informazioni.}
+\fdecl{int sigtimedwait(const sigset\_t *set, siginfo\_t *info, const
+ struct timespec *timeout)}
+\fdesc{Attende un segnale con le relative informazioni per un tempo massimo.}
+}
+
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno gli stessi valori di \func{sigwait} ai quali
+ si aggiunge per \func{sigtimedwait}:
+ \begin{errlist}
+ \item[\errcode{EAGAIN}] si è superato il timeout senza che un segnale atteso
+ sia stato ricevuto.
+ \end{errlist}
+}
+\end{funcproto}
+
+
+Entrambe le funzioni sono estensioni di \func{sigwait}. La prima permette di
+ricevere, oltre al numero del segnale, anche le informazioni ad esso associate
+tramite l'argomento \param{info}; in particolare viene restituito il numero
+del segnale nel campo \var{si\_signo}, la sua causa in \var{si\_code}, e se il
+segnale è stato immesso sulla coda con \func{sigqueue}, il valore di ritorno
+ad esso associato viene riportato in \var{si\_value}, che altrimenti è
+indefinito.
+
+La seconda è identica alla prima ma in più permette di specificare un timeout
+con l'argomento omonimo, scaduto il quale ritornerà con un errore. Se si
+specifica per \param{timeout} un puntatore nullo il comportamento sarà
+identico a \func{sigwaitinfo}. Se si specifica un tempo di timeout nullo e non
+ci sono segnali pendenti la funzione ritornerà immediatamente, in questo modo
+si può eliminare un segnale dalla coda senza dover essere bloccati qualora
+esso non sia presente.
+
+L'uso di queste funzioni è principalmente associato alla gestione dei segnali
+con i \textit{thread}. In genere esse vengono chiamate dal \textit{thread}
+incaricato della gestione, che al ritorno della funzione esegue il codice che
+usualmente sarebbe messo nel gestore, per poi ripetere la chiamata per
+mettersi in attesa del segnale successivo. Questo ovviamente comporta che non
+devono essere installati gestori, che solo il \textit{thread} di gestione deve
+usare \func{sigwait} e che i segnali gestiti in questa maniera, per evitare
+che venga eseguita l'azione predefinita, devono essere mascherati per tutti i
+\textit{thread}, compreso quello dedicato alla gestione, che potrebbe
+riceverlo fra due chiamate successive.
+
+
+\subsection{La gestione avanzata delle temporizzazioni}
+\label{sec:sig_timer_adv}
+
+Sia le funzioni per la gestione dei tempi viste in
+sez.~\ref{sec:sys_cpu_times} che quelle per la gestione dei timer di
+sez.~\ref{sec:sig_alarm_abort} sono state a lungo limitate dalla risoluzione
+massima dei tempi dell'orologio interno del kernel, che era quella ottenibile
+dal timer di sistema che governa lo \textit{scheduler}, e quindi limitate
+dalla frequenza dello stesso che si ricordi, come già illustrato in
+sez.~\ref{sec:proc_hierarchy}, è data dal valore della costante \texttt{HZ}.
+
+I contatori usati per il calcolo dei tempi infatti erano basati sul numero di
+\textit{jiffies} che vengono incrementati ad ogni \textit{clock tick} del
+timer di sistema, il che comportava anche, come accennato in
+sez.~\ref{sec:sig_alarm_abort} per \func{setitimer}, problemi per il massimo
+periodo di tempo copribile da alcuni di questi orologi, come quelli associati
+al \textit{process time} almeno fino a quando, con il kernel 2.6.16, non è
+stato rimosso il limite di un valore a 32 bit per i \textit{jiffies}.
+
+\itindbeg{POSIX~Timer~API}
+
+Nelle architetture moderne però tutti i computer sono dotati di temporizzatori
+hardware che possono supportare risoluzioni molto elevate, ed in maniera del
+tutto indipendente dalla frequenza scelta per il timer di sistema che governa
+lo \textit{scheduler}, normalmente si possono ottenere precisioni fino al
+microsecondo, andando molto oltre in caso di hardware dedicato.
+
+Per questo lo standard POSIX.1-2001 ha previsto una serie di nuove funzioni
+relative a quelli che vengono chiamati ``\textsl{orologi}
+\textit{real-time}'', in grado di supportare risoluzioni fino al
+nanosecondo. Inoltre le CPU più moderne sono dotate a loro volta di contatori
+ad alta definizione che consentono una grande accuratezza nella misura del
+tempo da esse dedicato all'esecuzione di un processo.
+
+Per usare queste funzionalità ed ottenere risoluzioni temporali più accurate,
+occorre però un opportuno supporto da parte del kernel, ed i cosiddetti
+\itindex{High~Resolution~Timer~(HRT)} \textit{high resolution timer} che
+consentono di fare ciò sono stati introdotti nel kernel ufficiale solo a
+partire dalla versione 2.6.21.\footnote{per il supporto deve essere stata
+ abilitata l'opzione di compilazione \texttt{CONFIG\_HIGH\_RES\_TIMERS}, il
+ supporto era però disponibile anche in precedenza nei patch facenti parte
+ dello sviluppo delle estensioni \textit{real-time} del kernel, per cui
+ alcune distribuzioni possono averlo anche con versioni precedenti del
+ kernel.} Le funzioni definite dallo standard POSIX per gestire orologi ad
+alta definizione però erano già presenti, essendo stata introdotte insieme ad
+altre funzioni per il supporto delle estensioni \textit{real-time} con il
+rilascio del kernel 2.6, ma la risoluzione effettiva era nominale.
+
+A tutte le implementazioni che si rifanno a queste estensioni è richiesto di
+disporre di una versione \textit{real-time} almeno per l'orologio generale di
+sistema, quello che mantiene il \textit{calendar time} (vedi
+sez.~\ref{sec:sys_time_base}), che in questa forma deve indicare il numero di
+secondi e nanosecondi passati a partire dal primo gennaio 1970 (\textit{The
+ Epoch}). Si ricordi infatti che l'orologio ordinario usato dal
+\textit{calendar time} riporta solo un numero di secondi, e che la risoluzione
+effettiva normalmente non raggiunge il nanosecondo (a meno di hardware
+specializzato). Oltre all'orologio generale di sistema possono essere
+presenti altri tipi di orologi \textit{real-time}, ciascuno dei quali viene
+identificato da un opportuno valore di una variabile di tipo
+\type{clockid\_t}; un elenco di quelli disponibili su Linux è riportato in
+tab.~\ref{tab:sig_timer_clockid_types}.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{CLOCK\_REALTIME} & Orologio \textit{real-time} di sistema, può
+ essere impostato solo con privilegi
+ amministrativi.\\
+ \constd{CLOCK\_MONOTONIC} & Orologio che indica un tempo monotono
+ crescente (a partire da un tempo iniziale non
+ specificato) che non può essere modificato e
+ non cambia neanche in caso di reimpostazione
+ dell'orologio di sistema.\\
+ \constd{CLOCK\_PROCESS\_CPUTIME\_ID}& Contatore del tempo di CPU usato
+ da un processo (il \textit{process time} di
+ sez.~\ref{sec:sys_cpu_times}, nel totale di
+ \textit{system time} e \textit{user time})
+ comprensivo di tutto il tempo di CPU usato
+ da eventuali \textit{thread}.\\
+ \constd{CLOCK\_THREAD\_CPUTIME\_ID}& Contatore del tempo di CPU
+ (\textit{user time} e \textit{system time})
+ usato da un singolo \textit{thread}.\\
+ \hline
+ \constd{CLOCK\_MONOTONIC\_RAW}&Simile al precedente, ma non subisce gli
+ aggiustamenti dovuti all'uso di NTP (viene
+ usato per fare riferimento ad una fonte
+ hardware). Questo orologio è specifico di
+ Linux, ed è disponibile a partire dal kernel
+ 2.6.28.\\
+ \constd{CLOCK\_BOOTTIME} & Identico a \const{CLOCK\_MONOTONIC} ma tiene
+ conto anche del tempo durante il quale il
+ sistema è stato sospeso (nel caso di
+ sospensione in RAM o \textsl{ibernazione} su
+ disco. Questo orologio è specifico di Linux,
+ ed è disponibile a partire dal kernel
+ 2.6.39.\\
+ \constd{CLOCK\_REALTIME\_ALARM}&Identico a \const{CLOCK\_REALTIME}, ma se
+ usato per un timer il sistema sarà riattivato
+ anche se è in sospensione. Questo orologio è
+ specifico di Linux, ed è disponibile a
+ partire dal kernel 3.0.\\
+ \constd{CLOCK\_BOOTTIME\_ALARM}&Identico a \const{CLOCK\_BOOTTIME}, ma se
+ usato per un timer il sistema sarà riattivato
+ anche se è in sospensione. Questo orologio è
+ specifico di Linux, ed è disponibile a
+ partire dal kernel 3.0.\\
+% \const{} & .\\
+ \hline
+ \end{tabular}
+ \caption{Valori possibili per una variabile di tipo \typed{clockid\_t}
+ usata per indicare a quale tipo di orologio si vuole fare riferimento.}
+ \label{tab:sig_timer_clockid_types}
+\end{table}
+
+
+% TODO: dal 4.17 CLOCK_MONOTONIC e CLOCK_BOOTTIME sono identici vedi
+% https://lwn.net/Articles/751651/ e
+% https://git.kernel.org/linus/d6ed449afdb38f89a7b38ec50e367559e1b8f71f
+% change reverted, vedi: https://lwn.net/Articles/752757/
+
+% NOTE: dal 3.0 anche i cosiddetti Posix Alarm Timers, con
+% CLOCK_REALTIME_ALARM vedi http://lwn.net/Articles/429925/
+% TODO: dal 3.10 anche CLOCK_TAI
+
+% TODO seguire l'evoluzione delle nuove syscall per il problema del 2038,
+% iniziate ad entrare nel kernel dal 5.1, vedi
+% https://lwn.net/Articles/776435/, https://lwn.net/Articles/782511/,
+% https://git.kernel.org/linus/b1b988a6a035
+
+Per poter utilizzare queste funzionalità la \acr{glibc} richiede che la
+macro \macro{\_POSIX\_C\_SOURCE} sia definita ad un valore maggiore o uguale
+di \texttt{199309L} (vedi sez.~\ref{sec:intro_gcc_glibc_std}), inoltre i
+programmi che le usano devono essere collegati con la libreria delle
+estensioni \textit{real-time} usando esplicitamente l'opzione \texttt{-lrt}.
+
+Si tenga presente inoltre che la disponibilità di queste funzionalità avanzate
+può essere controllato dalla definizione della macro \macrod{\_POSIX\_TIMERS}
+ad un valore maggiore di 0, e che le ulteriori macro
+\macrod{\_POSIX\_MONOTONIC\_CLOCK}, \macrod{\_POSIX\_CPUTIME} e
+\macrod{\_POSIX\_THREAD\_CPUTIME} indicano la presenza dei rispettivi orologi
+di tipo \const{CLOCK\_MONOTONIC}, \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
+\const{CLOCK\_THREAD\_CPUTIME\_ID}; tutte queste macro sono definite in
+\headfile{unistd.h}, che pertanto deve essere incluso per poterle
+controllarle. Infine se il kernel ha il supporto per gli \textit{high
+ resolution timer} un elenco degli orologi e dei timer può essere ottenuto
+tramite il file \procfile{/proc/timer\_list}.
+
+Le due funzioni che ci consentono rispettivamente di modificare o leggere il
+valore per uno degli orologi \textit{real-time} sono \funcd{clock\_settime} e
+\funcd{clock\_gettime}; i rispettivi prototipi sono:
+
+\begin{funcproto}{
+\fhead{time.h}
+\fdecl{int clock\_settime(clockid\_t clockid, const struct timespec *tp)}
+\fdesc{Imposta un orologio \textit{real-time}.}
+\fdecl{int clock\_gettime(clockid\_t clockid, struct timespec *tp)}
+\fdesc{Legge un orologio \textit{real-time}.}
+}
+
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EFAULT}] l'indirizzo \param{tp} non è valido.
+ \item[\errcode{EINVAL}] il valore specificato per \param{clockid} non è
+ valido o il relativo orologio \textit{real-time} non è supportato dal
+ sistema.
+ \item[\errcode{EPERM}] non si ha il permesso di impostare l'orologio
+ indicato (solo per \func{clock\_settime}).
+ \end{errlist}
+}
+\end{funcproto}
+
+Entrambe le funzioni richiedono che si specifichi come primo argomento il tipo
+di orologio su cui si vuole operare con uno dei valori di
+tab.~\ref{tab:sig_timer_clockid_types} o con il risultato di una chiamata a
+\func{clock\_getcpuclockid} (che tratteremo a breve), il secondo argomento
+invece è sempre il puntatore \param{tp} ad una struttura \struct{timespec}
+(vedi fig.~\ref{fig:sys_timespec_struct}) che deve essere stata
+precedentemente allocata. Per \func{clock\_settime} questa dovrà anche essere
+stata inizializzata con il valore che si vuole impostare sull'orologio, mentre
+per \func{clock\_gettime} verrà restituito al suo interno il valore corrente
+dello stesso.
+
+Si tenga presente inoltre che per eseguire un cambiamento sull'orologio
+generale di sistema \const{CLOCK\_REALTIME} occorrono i privilegi
+amministrativi;\footnote{ed in particolare la \textit{capability}
+ \const{CAP\_SYS\_TIME}.} inoltre ogni cambiamento ad esso apportato non avrà
+nessun effetto sulle temporizzazioni effettuate in forma relativa, come quelle
+impostate sulle quantità di \textit{process time} o per un intervallo di tempo
+da trascorrere, ma solo su quelle che hanno richiesto una temporizzazione ad
+un istante preciso (in termini di \textit{calendar time}). Si tenga inoltre
+presente che nel caso di Linux \const{CLOCK\_REALTIME} è l'unico orologio per
+cui si può effettuare una modifica, infatti nonostante lo standard preveda la
+possibilità di modifiche anche per \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
+\const{CLOCK\_THREAD\_CPUTIME\_ID}, il kernel non le consente.
+
+Oltre alle due funzioni precedenti, lo standard POSIX prevede una terza
+funzione di sistema che consenta di ottenere la risoluzione effettiva fornita
+da un certo orologio, la funzione è \funcd{clock\_getres} ed il suo prototipo
+è:
+
+\begin{funcproto}{
+\fhead{time.h}
+\fdecl{int clock\_getres(clockid\_t clockid, struct timespec *res)}
+\fdesc{Legge la risoluzione di un orologio \textit{real-time}.}
+}