+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 funzione principale dell'interfaccia POSIX.1 per i 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{prototype}{signal.h}{int sigaction(int signum, const struct sigaction
+ *act, struct sigaction *oldact)}
+
+ Installa una nuova azione per il segnale \param{signum}.
+
+ \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
+ errore, nel qual caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido o si è
+ cercato di installare il gestore per \signal{SIGKILL} o
+ \signal{SIGSTOP}.
+ \item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
+ \end{errlist}}
+\end{prototype}
+
+La funzione serve ad installare una nuova \textsl{azione} per il segnale
+\param{signum}; si parla di \textsl{azione} e non di \textsl{gestore}
+come nel caso di \func{signal}, in quanto la funzione consente di specificare
+le varie caratteristiche della risposta al segnale, non solo la funzione che
+verrà eseguita alla sua occorrenza. Per questo lo standard raccomanda di
+usare sempre questa funzione al posto di \func{signal} (che in genere viene
+definita tramite essa), in quanto permette un controllo completo su tutti gli
+aspetti della gestione di un segnale, sia pure al prezzo di una maggiore
+complessità d'uso.
+
+Se il puntatore \param{act} non è nullo, la funzione installa la nuova azione
+da esso specificata, se \param{oldact} non è nullo il valore dell'azione
+corrente viene restituito indietro. Questo permette (specificando \param{act}
+nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
+che non consente di ottenere l'azione corrente senza installarne una nuova.
+
+Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
+tramite la quale si specificano tutte le caratteristiche dell'azione associata
+ad un segnale. Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
+definita secondo quanto riportato in fig.~\ref{fig:sig_sigaction}. Il campo
+\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
+più usato.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\textwidth}
+ \includestruct{listati/sigaction.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{sigaction}.}
+ \label{fig:sig_sigaction}
+\end{figure}
+
+Il campo \var{sa\_mask} serve ad indicare l'insieme dei segnali che devono
+essere bloccati durante l'esecuzione del gestore, ad essi viene comunque
+sempre aggiunto il segnale che ne ha causato la chiamata, a meno che non si
+sia specificato con \var{sa\_flag} un comportamento diverso. Quando il
+gestore ritorna comunque la maschera dei segnali bloccati (vedi
+sez.~\ref{sec:sig_sigmask}) viene ripristinata al valore precedente
+l'invocazione.
+
+L'uso di questo campo permette ad esempio di risolvere il problema residuo
+dell'implementazione di \code{sleep} mostrata in
+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
+ \const{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}.\\
+ \const{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.\\
+ \const{SA\_ONESHOT} & Nome obsoleto, sinonimo non standard di
+ \const{SA\_RESETHAND}; da evitare.\\
+ \const{SA\_ONSTACK} & Stabilisce l'uso di uno \itindex{stack}
+ \textit{stack} alternativo per l'esecuzione del
+ gestore (vedi
+ sez.~\ref{sec:sig_specific_features}).\\
+ \const{SA\_RESTART} & Riavvia automaticamente le \textit{slow system
+ call} quando vengono interrotte dal suddetto
+ segnale; riproduce cioè il comportamento standard
+ di BSD.\index{system~call~lente}\\
+ \const{SA\_NODEFER} & Evita che il segnale corrente sia bloccato durante
+ l'esecuzione del gestore.\\
+ \const{SA\_NOMASK} & Nome obsoleto, sinonimo non standard di
+ \const{SA\_NODEFER}.\\
+ \const{SA\_SIGINFO} & Deve essere specificato quando si vuole usare un
+ gestore in forma estesa usando
+ \var{sa\_sigaction} al posto di
+ \var{sa\_handler}.\\
+ \const{SA\_NOCLDWAIT}& Se il segnale è \signal{SIGCHLD} allora i processi
+ figli non diventano \itindex{zombie}
+ \textit{zombie} quando terminano.\footnotemark \\
+ \hline
+ \end{tabular}
+ \caption{Valori del campo \var{sa\_flag} della struttura \struct{sigaction}.}
+ \label{tab:sig_sa_flag}
+\end{table}
+
+\footnotetext{questa funzionalità è stata introdotta nel kernel 2.6 e va a
+ modificare il comportamento di \func{waitpid}.}
+
+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},\footnote{i due campi devono essere usati in maniera
+ alternativa, in certe implementazioni questi campi vengono addirittura
+ definiti come \direct{union}.} 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}.
+
+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]{\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}.
+
+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.
+
+\begin{table}[!htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{SI\_USER} & generato da \func{kill} o \func{raise}.\\
+ \const{SI\_KERNEL} & inviato dal kernel.\\
+ \const{SI\_QUEUE} & inviato con \func{sigqueue} (vedi
+ sez.~\ref{sec:sig_real_time}).\\
+ \const{SI\_TIMER} & scadenza di un POSIX timer
+ (vedi sez.~\ref{sec:sig_timer_adv}).\\
+ \const{SI\_MESGQ} & inviato al cambiamento di stato di una coda di
+ messaggi POSIX (vedi
+ sez.~\ref{sec:ipc_posix_mq}).\footnotemark\\
+ \const{SI\_ASYNCIO}& una operazione di I/O asincrono (vedi
+ sez.~\ref{sec:file_asyncronous_access}) è stata
+ completata.\\
+ \const{SI\_SIGIO} & segnale di \signal{SIGIO} da una coda (vedi
+ sez.~\ref{sec:file_asyncronous_operation}).\\
+ \const{SI\_TKILL} & inviato da \func{tkill} o \func{tgkill} (vedi
+ sez.~\ref{cha:threads_xxx}).\footnotemark\\
+ \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}
+
+\footnotetext[24]{introdotto con il kernel 2.6.6.}
+\footnotetext{introdotto con il kernel 2.4.19.}
+
+In questo caso il valore del campo \var{si\_code} deve essere verificato nei
+confronti delle diverse costanti previste per ciascuno di detti
+segnali;\footnote{dato che si tratta di una costante, 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.\footnote{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
+ \const{ILL\_ILLOPC} & codice di operazione illegale.\\
+ \const{ILL\_ILLOPN} & operando illegale.\\
+ \const{ILL\_ILLADR} & modo di indirizzamento illegale.\\
+ \const{ILL\_ILLTRP} & trappola di processore illegale.\\
+ \const{ILL\_PRVOPC} & codice di operazione privilegiato.\\
+ \const{ILL\_PRVREG} & registro privilegiato.\\
+ \const{ILL\_COPROC} & errore del coprocessore.\\
+ \const{ILL\_BADSTK} & errore nello stack interno.\\
+ \hline
+ \const{FPE\_INTDIV} & divisione per zero intera.\\
+ \const{FPE\_INTOVF} & overflow intero.\\
+ \const{FPE\_FLTDIV} & divisione per zero in virgola mobile.\\
+ \const{FPE\_FLTOVF} & overflow in virgola mobile.\\
+ \const{FPE\_FLTUND} & underflow in virgola mobile.\\
+ \const{FPE\_FLTRES} & risultato in virgola mobile non esatto.\\
+ \const{FPE\_FLTINV} & operazione in virgola mobile non valida.\\
+ \const{FPE\_FLTSUB} & mantissa? fuori intervallo.\\
+ \hline
+ \const{SEGV\_MAPERR} & indirizzo non mappato.\\
+ \const{SEGV\_ACCERR} & permessi non validi per l'indirizzo.\\
+ \hline
+ \const{BUS\_ADRALN} & allineamento dell'indirizzo non valido.\\
+ \const{BUS\_ADRERR} & indirizzo fisico inesistente.\\
+ \const{BUS\_OBJERR} & errore hardware sull'indirizzo.\\
+ \hline
+ \const{TRAP\_BRKPT} & breakpoint sul processo.\\
+ \const{TRAP\_TRACE} & trappola di tracciamento del processo.\\
+ \hline
+ \const{CLD\_EXITED} & il figlio è uscito.\\
+ \const{CLD\_KILLED} & il figlio è stato terminato.\\
+ \const{CLD\_DUMPED} & il figlio è terminato in modo anormale.\\
+ \const{CLD\_TRAPPED} & un figlio tracciato ha raggiunto una trappola.\\
+ \const{CLD\_STOPPED} & il figlio è stato fermato.\\
+ \const{CLD\_CONTINUED}& il figlio è ripartito.\\
+ \hline
+ \const{POLL\_IN} & disponibili dati in ingresso.\\
+ \const{POLL\_OUT} & spazio disponibile sul buffer di uscita.\\
+ \const{POLL\_MSG} & disponibili messaggi in ingresso.\\
+ \const{POLL\_ERR} & errore di I/O.\\
+ \const{POLL\_PRI} & disponibili dati di alta priorità in ingresso.\\
+ \const{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 \direct{union} ed i
+valori eventualmente presenti dipendono dal segnale, 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 \itindex{out-of-band} dati urgenti
+(vedi sez.~\ref{sec:TCP_urgent_data}) su un socket, il segnale inviato alla
+scadenza di un timer POSIX (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). Si noti come, essendo la
+funzione estremamente semplice, essa è definita come
+\direct{inline};\footnote{la direttiva \direct{inline} 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 user space, non sono sempre adatte). In
+ tal caso infatti le istruzioni per creare un nuovo frame nello
+ \itindex{stack} \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.} per semplificare ulteriormente la definizione si è poi
+definito un apposito tipo \texttt{SigFunc}.
+
+
+
+\subsection{La gestione della \textsl{maschera dei segnali} o
+ \textit{signal mask}}
+\label{sec:sig_sigmask}
+
+\itindbeg{signal~mask}
+Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like
+permettono di bloccare temporaneamente (o di eliminare completamente,
+impostando \const{SIG\_IGN} come azione) 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 \textit{signal mask} 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, 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 (nel caso
+in questione la sezione fra il controllo e la eventuale cancellazione del flag
+che testimoniava l'avvenuta occorrenza del segnale) in modo da essere sicuri
+che essi siano eseguite senza interruzioni.
+
+Le operazioni più semplici, come l'assegnazione o il controllo di una
+variabile (per essere sicuri si può usare il tipo \type{sig\_atomic\_t}) di
+norma sono atomiche; quando si devono eseguire operazioni più complesse si può
+invece usare la funzione \funcd{sigprocmask} che permette di bloccare uno o
+più segnali; il suo prototipo è:
+\begin{prototype}{signal.h}
+{int sigprocmask(int how, const sigset\_t *set, sigset\_t *oldset)}
+
+ Cambia la \textsl{maschera dei segnali} del processo corrente.
+
+ \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
+ errore, nel qual caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
+ \item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
+ \end{errlist}}
+\end{prototype}
+
+La funzione usa l'insieme di segnali dato all'indirizzo \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
+ \const{SIG\_BLOCK} & L'insieme dei segnali bloccati è l'unione fra
+ quello specificato e quello corrente.\\
+ \const{SIG\_UNBLOCK} & I segnali specificati in \param{set} sono rimossi
+ dalla maschera dei segnali, specificare la
+ cancellazione di un segnale non bloccato è legale.\\
+ \const{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
+\index{sezione~critica} 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 alla conclusione del terminatore.
+
+Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
+dei casi di \itindex{race~condition} \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
+\funcd{sigsuspend}, il cui prototipo è:
+\begin{prototype}{signal.h}
+{int sigsuspend(const sigset\_t *mask)}
+
+ Imposta la \textit{signal mask} specificata, mettendo in attesa il processo.
+
+ \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
+ errore, nel qual caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
+ \item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
+ \end{errlist}}
+\end{prototype}
+
+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 \itindex{race~condition} \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
+\itindex{deadlock} deadlock dovuto all'arrivo del segnale prima
+dell'esecuzione di \func{sigsuspend}.
+
+\itindend{signal~mask}
+
+
+\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!sicure|(}
+
+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;\footnote{non è riportata una lista specifica delle funzioni
+ sicure per Linux, si suppone pertanto che siano quelle richieste dallo
+ standard.} secondo quanto riportato 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!sicure|)}
+
+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 \index{variabili!globali}
+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 dalle
+ \acr{glibc} 2.1.} in particolare sono stati superati tre limiti fondamentali
+dei segnali classici:
+\begin{basedescript}{\desclabelwidth{1cm}\desclabelstyle{\nextlinelabel}}
+\item[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[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[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
+\const{SIGRTMIN} e \const{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 vendono usati
+dalle \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{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ò essere 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}.\footnote{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} (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]{\textwidth}
+ \includestruct{listati/sigval_t.h}
+ \end{minipage}
+ \normalsize
+ \caption{La definizione dell'unione \structd{sigval}, definita anche come
+ tipo \type{sigval\_t}.}
+ \label{fig:sig_sigval}
+\end{figure}
+
+Questo è una \direct{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 indirizzo, se usata nella forma
+\var{sival\_ptr}. L'unione viene usata dai segnali \textit{real-time} e da
+vari meccanismi di notifica\footnote{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}).} per restituire dati al gestore
+del segnale; in alcune definizioni essa viene identificata anche con
+l'abbreviazione \type{sigval\_t}.
+
+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 \struct{sigval}; per questo motivo lo standard ha previsto una
+nuova funzione, \funcd{sigqueue}, il cui prototipo è:
+\begin{prototype}{signal.h}
+ {int sigqueue(pid\_t pid, int signo, const union sigval value)}
+
+ Invia il segnale \param{signo} al processo \param{pid}, restituendo al
+ gestore il valore \param{value}.
+
+ \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{EAGAIN}] la coda è esaurita, ci sono già
+ \const{SIGQUEUE\_MAX} segnali in attesa si consegna.
+ \item[\errcode{EPERM}] non si hanno privilegi appropriati per inviare il
+ segnale al processo specificato.
+ \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per
+ \param{signo}.
+ \end{errlist}
+ ed inoltre \errval{ENOMEM}.}
+\end{prototype}
+
+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 riporterà nel campo
+\var{si\_code} di \struct{siginfo\_t} il valore \const{SI\_QUEUE} e il campo
+\var{si\_value} riceverà quanto inviato con \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.
+
+Secondo lo standard POSIX la profondità della coda è indicata dalla costante
+\const{SIGQUEUE\_MAX},\footnote{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,
+\const{\_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
+\sysctlfile{kernel/rtsig-max};\footnote{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 che permettono di
+gestire l'attesa di segnali specifici su una coda, esse servono in particolar
+modo nel caso dei \itindex{thread} \textit{thread}, in cui si possono usare i
+segnali \textit{real-time} come meccanismi di comunicazione elementare; la
+prima di queste funzioni è \funcd{sigwait}, il cui prototipo è:
+\begin{prototype}{signal.h}
+ {int sigwait(const sigset\_t *set, int *sig)}
+
+ Attende che uno dei segnali specificati in \param{set} sia pendente.
+
+ \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{EINTR}] la funzione è stata interrotta.
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per
+ \param{set}.
+ \end{errlist}
+ ed inoltre \errval{EFAULT}.}
+\end{prototype}
+
+La funzione estrae dall'insieme dei segnali pendenti uno qualunque dei segnali
+specificati da \param{set}, il cui valore viene restituito in \param{sig}. Se
+sono pendenti più segnali, viene estratto quello a priorità più alta (cioè 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, anch'esse usate
+prevalentemente con i \itindex{thread} \textit{thread}; \funcd{sigwaitinfo} e
+\funcd{sigtimedwait}, i relativi prototipi sono:
+\begin{functions}
+ \headdecl{signal.h}
+
+ \funcdecl{int sigwaitinfo(const sigset\_t *set, siginfo\_t *info)}
+
+ Analoga a \func{sigwait}, ma riceve anche le informazioni associate al
+ segnale in \param{info}.
+
+ \funcdecl{int sigtimedwait(const sigset\_t *set, siginfo\_t *info, const
+ struct timespec *timeout)}
+
+ Analoga a \func{sigwaitinfo}, con un la possibilità di specificare un
+ timeout in \param{timeout}.
+
+
+ \bodydesc{Le funzioni restituiscono 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei valori già visti per
+ \func{sigwait}, ai quali si aggiunge, per \func{sigtimedwait}:
+ \begin{errlist}
+ \item[\errcode{EAGAIN}] si è superato il timeout senza che un segnale atteso
+ fosse emesso.
+ \end{errlist}
+}
+\end{functions}
+
+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 \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,
+scaduto il quale ritornerà con un errore. Se si specifica 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.
+
+\itindbeg{thread}
+
+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.
+
+\itindend{thread}
+
+
+\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},\footnote{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 tempo infatti erano
+basati sul numero di \itindex{jiffies} \textit{jiffies} che vengono
+incrementati ad ogni \textit{clock tick} del timer di sistema.\footnote{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}.}
+
+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};\footnote{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
+\textit{high resolution timer} che consentono di fare ciò sono stati
+introdotti nel kernel ufficiale solo a partire dalla versione
+2.6.21.\footnote{deve essere stata abilitata l'opzione di compilazione
+ \texttt{CONFIG\_HIGH\_RES\_TIMERS}, erano però disponibili anche in
+ precedenza come patch facenti parte dello sviluppo delle estensioni
+ \textit{real-time} del kernel, per cui alcune distribuzioni possono avere
+ questo supporto 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}).\footnote{si ricordi 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
+ \const{CLOCK\_REALTIME} & Orologio \textit{real-time} di sistema, può
+ essere impostato solo con privilegi
+ amministrativi.\\
+ \const{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.\\
+ \const{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).\footnotemark\\
+ \const{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 \itindex{thread}
+ \textit{thread}.\\
+ \const{CLOCK\_THREAD\_CPUTIME\_ID}& contatore del tempo di CPU
+ (\textit{user time} e \textit{system time})
+ usato da un singolo \itindex{thread}
+ \textit{thread}.\\
+% \const{} & .\\
+ \hline
+ \end{tabular}
+ \caption{Valori possibili per una variabile di tipo \type{clockid\_t}
+ usata per indicare a quale tipo di orologio si vuole fare riferimento.}
+ \label{tab:sig_timer_clockid_types}
+\end{table}
+
+\footnotetext{specifico di Linux, introdotto a partire dal kernel 2.6.28, non
+ previsto da POSIX e non presente in altri sistemi unix-like.}
+
+% TODO: aggiungere le estensioni introdotte con il 2.6.38, verificandone il
+% funzionamento, vedi http://lwn.net/Articles/429595/
+% TODO: dal 2.6.39 anche CLOCK_BOOTTIME_ALARM e CLOCK_BOOTTIME, vedi
+% http://lwn.net/Articles/429925/
+% TODP: dal 3.0 anche i cosiddetti Posix Alarm Timers, con
+% CLOCK_REALTIME_ALARM vedi http://lwn.net/Articles/429925/
+
+Per poter utilizzare queste funzionalità le \acr{glibc} richiedono 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
+\macro{\_POSIX\_TIMERS} ad un valore maggiore di 0, e che le ulteriori macro
+\macro{\_POSIX\_MONOTONIC\_CLOCK}, \macro{\_POSIX\_CPUTIME} e
+\macro{\_POSIX\_THREAD\_CPUTIME} indicano la presenza dei rispettivi orologi
+di tipo \const{CLOCK\_MONOTONIC}, \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
+\const{CLOCK\_PROCESS\_CPUTIME\_ID}.\footnote{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{functions}
+ \headdecl{time.h}
+
+ \funcdecl{int clock\_settime(clockid\_t clockid, const struct timespec *tp)}
+ \funcdecl{int clock\_gettime(clockid\_t clockid, struct timespec *tp)}
+
+ Imposta o legge un orologio \textit{real-time}.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+ \begin{errlist}
+ \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}).
+ \item[\errcode{EFAULT}] l'indirizzo \param{tp} non è valido.
+ \end{errlist}
+}
+\end{functions}
+
+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; nel primo caso questa dovrà anche essere stata
+inizializzata con il valore che si vuole impostare sull'orologio, mentre nel
+secondo 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 che consenta di ottenere la risoluzione effettiva fornita da un certo
+orologio, la funzione è \funcd{clock\_getres} ed il suo prototipo è:
+\begin{functions}
+ \headdecl{time.h}
+
+ \funcdecl{int clock\_getres(clockid\_t clockid, struct timespec *res)}
+
+ Legge la risoluzione di un orologio \textit{real-time}.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] il valore specificato per \param{clockid} non è
+ valido.
+ \item[\errcode{EFAULT}] l'indirizzo di \param{res} non è valido.
+ \end{errlist}
+}
+\end{functions}
+
+La funzione richiede come primo argomento l'indicazione dell'orologio di cui
+si vuole conoscere la risoluzione (effettuata allo stesso modo delle due
+precedenti) e questa verrà restituita in una struttura \struct{timespec}
+all'indirizzo puntato dall'argomento \param{res}.
+
+Come accennato il valore di questa risoluzione dipende sia dall'hardware
+disponibile che dalla implementazione delle funzioni, e costituisce il limite
+minimo di un intervallo di tempo che si può indicare. Qualunque valore si
+voglia utilizzare nelle funzioni di impostazione che non corrisponda ad un
+multiplo intero di questa risoluzione, sarà troncato in maniera automatica.
+
+Si tenga presente inoltre che con l'introduzione degli \textit{high resolution
+ timer} i due orologi \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
+\const{CLOCK\_THREAD\_CPUTIME\_ID} fanno riferimento ai contatori presenti in
+opportuni registri interni del processore; questo sui sistemi multiprocessore
+può avere delle ripercussioni sulla precisione delle misure di tempo che vanno
+al di là della risoluzione teorica ottenibile con \func{clock\_getres}, che
+può essere ottenuta soltanto quando si è sicuri che un processo (o un
+\textit{thread}) sia sempre stato eseguito sullo stesso processore.
+
+Con i sistemi multiprocessore infatti ogni singola CPU ha i suoi registri
+interni, e se ciascuna di esse utilizza una base di tempo diversa (se cioè il
+segnale di temporizzazione inviato ai processori non ha una sola provenienza)
+in genere ciascuna di queste potrà avere delle frequenze leggermente diverse,
+e si otterranno pertanto dei valori dei contatori scorrelati fra loro, senza
+nessuna possibilità di sincronizzazione.
+
+Il problema si presenta, in forma più lieve, anche se la base di tempo è la
+stessa, dato che un sistema multiprocessore non avvia mai tutte le CPU allo
+stesso istante, si potrà così avere di nuovo una differenza fra i contatori,
+soggetta però soltanto ad uno sfasamento costante. Per questo caso il kernel
+per alcune architetture ha del codice che consente di ridurre al minimo la
+differenza, ma non può essere comunque garantito che questa si annulli (anche
+se in genere risulta molto piccola e trascurabile nella gran parte dei casi).
+
+Per poter gestire questo tipo di problematiche lo standard ha previsto una
+apposita funzione che sia in grado di ottenere l'identificativo dell'orologio
+associato al \textit{process time} di un processo, la funzione è
+\funcd{clock\_getcpuclockid} ed il suo prototipo è:
+\begin{functions}
+ \headdecl{time.h}
+
+ \funcdecl{int clock\_getcpuclockid(pid\_t pid, clockid\_t *clockid)}
+
+ Ottiene l'identificatore dell'orologio di CPU usato da un processo.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo o un numero positivo
+ in caso di errore, nel qual caso \var{errno} assumerà uno dei seguenti
+ valori:
+ \begin{errlist}
+ \item[\errcode{ENOSYS}] non c'è il supporto per ottenere l'orologio relativo
+ al \textit{process time} di un altro processo, e \param{pid} non
+ corrisponde al processo corrente.
+ \item[\errcode{EPERM}] il chiamante non ha il permesso di accedere alle
+ informazioni relative al processo \param{pid}.
+ \item[\errcode{ESRCH}] non esiste il processo \param{pid}.
+ \end{errlist}
+}
+\end{functions}
+
+
+La funzione ritorna l'identificativo di un orologio di sistema associato ad un
+processo indicato tramite l'argomento \param{pid}. Un utente normale, posto
+che il kernel sia sufficientemente recente da supportare questa funzionalità,
+può accedere soltanto ai dati relativi ai propri processi.
+
+Del tutto analoga a \func{clock\_getcpuclockid}, ma da utilizzare per ottenere
+l'orologio associato ad un \textit{thread} invece che a un processo, è
+\funcd{pthread\_getcpuclockid},\footnote{per poter usare la funzione, come per
+ qualunque funzione che faccia riferimento ai \textit{thread}, occorre
+ effettuare il collegamento alla relativa libreria di gestione compilando il
+ programma con \texttt{-lpthread}.} il cui prototipo è:
+\begin{functions}
+ \headdecl{pthread.h}
+ \headdecl{time.h}
+
+ \funcdecl{int pthread\_getcpuclockid(pthread\_t thread, clockid\_t *clockid)}
+
+ Ottiene l'identificatore dell'orologio di CPU associato ad un
+ \textit{thread}.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo o un numero positivo
+ in caso di errore, nel qual caso \var{errno} assumerà uno dei seguenti
+ valori:
+ \begin{errlist}
+ \item[\errcode{ENOENT}] la funzione non è supportata dal sistema.
+ \item[\errcode{ESRCH}] non esiste il \textit{thread} identificato
+ da \param{thread}.
+ \end{errlist}
+}
+\end{functions}
+
+% TODO, dal 2.6.39 aggiunta clock_adjtime
+% TODO manca clock_nanosleep
+
+Con l'introduzione degli orologi ad alta risoluzione è divenuto possibile
+ottenere anche una gestione più avanzata degli allarmi; abbiamo già visto in
+sez.~\ref{sec:sig_alarm_abort} come l'interfaccia di \func{setitimer} derivata
+da BSD presenti delle serie limitazioni,\footnote{in particolare la
+ possibilità di perdere un segnale sotto carico.} tanto che nello standard
+POSIX.1-2008 questa viene marcata come obsoleta, e ne viene fortemente
+consigliata la sostituzione con nuova interfaccia definita dallo standard
+POSIX.1-2001 che va sotto il nome di \textit{Posix Timer API}. Questa
+interfaccia è stata introdotta a partire dal kernel 2.6, anche se il supporto
+di varie funzionalità è stato aggiunto solo in un secondo tempo.
+
+Una delle principali differenze della nuova interfaccia è che un processo può
+utilizzare un numero arbitrario di timer; questi vengono creati (ma non
+avviati) tramite la funzione \funcd{timer\_create}, il cui prototipo è:
+\begin{functions}
+ \headdecl{signal.h}
+ \headdecl{time.h}
+
+ \funcdecl{int timer\_create(clockid\_t clockid, struct sigevent *evp,
+ timer\_t *timerid)}
+
+ Crea un nuovo timer Posix.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+ \begin{errlist}
+ \item[\errcode{EAGAIN}] fallimento nel tentativo di allocare le strutture
+ dei timer.
+ \item[\errcode{EINVAL}] uno dei valori specificati per \param{clockid} o per
+ i campi \var{sigev\_notify}, \var{sigev\_signo} o
+ \var{sigev\_notify\_thread\_id} di \param{evp} non è valido.
+ \item[\errcode{ENOMEM}] errore di allocazione della memoria.
+ \end{errlist}
+}
+\end{functions}
+
+La funzione richiede tre argomenti: il primo argomento serve ad indicare quale
+tipo di orologio si vuole utilizzare e prende uno dei valori di
+tab.~\ref{tab:sig_timer_clockid_types},\footnote{di detti valori però non è
+ previsto l'uso di \const{CLOCK\_MONOTONIC\_RAW} mentre
+ \const{CLOCK\_PROCESS\_CPUTIME\_ID} e \const{CLOCK\_THREAD\_CPUTIME\_ID}
+ sono disponibili solo a partire dal kernel 2.6.12.} si può così fare
+riferimento sia ad un tempo assoluto che al tempo utilizzato dal processo (o
+\textit{thread}) stesso.
+
+Il secondo argomento richiede una trattazione più dettagliata, in quanto
+introduce una struttura di uso generale, \struct{sigevent}, che viene
+utilizzata anche da altre funzioni, come quelle per l'I/O asincrono (vedi
+sez.~\ref{sec:file_asyncronous_io}) o le code di messaggi POSIX (vedi
+sez.~\ref{sec:ipc_posix_mq})) e che serve ad indicare in maniera generica un
+meccanismo di notifica.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\textwidth}
+ \includestruct{listati/sigevent.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{sigevent}, usata per specificare in maniera
+ generica diverse modalità di notifica degli eventi.}
+ \label{fig:struct_sigevent}
+\end{figure}
+
+La struttura \struct{sigevent} (accessibile includendo \headfile{time.h}) è
+riportata in fig.~\ref{fig:struct_sigevent};\footnote{la definizione effettiva
+ dipende dall'implementazione, quella mostrata è la versione descritta nella
+ pagina di manuale di \func{timer\_create}.} il campo \var{sigev\_notify} è
+il più importante essendo quello che indica le modalità della notifica, gli
+altri dipendono dal valore che si è specificato per \var{sigev\_notify}, si
+sono riportati in tab.~\ref{tab:sigevent_sigev_notify}. La scelta del
+meccanismo di notifica viene fatta impostando uno dei valori di
+tab.~\ref{tab:sigevent_sigev_notify} per \var{sigev\_notify}, e fornendo gli
+eventuali ulteriori argomenti necessari a secondo della scelta
+effettuata. Diventa così possibile indicare l'uso di un segnale o l'esecuzione
+(nel caso di uso dei \textit{thread}) di una funzione di modifica in un
+\textit{thread} dedicato.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|p{10cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{SIGEV\_NONE} & Non viene inviata nessuna notifica.\\
+ \const{SIGEV\_SIGNAL} & La notifica viene effettuata inviando al processo
+ chiamante il segnale specificato dal campo
+ \var{sigev\_signo}; se il gestore di questo
+ segnale è stato installato con
+ \const{SA\_SIGINFO} gli verrà restituito il
+ valore specificato con \var{sigev\_value} (una
+ \direct{union} \texttt{sigval}, la cui definizione
+ è in fig.~\ref{fig:sig_sigval}) come valore del
+ campo \var{si\_value} di \struct{siginfo\_t}.\\
+ \const{SIGEV\_THREAD} & La notifica viene effettuata creando un nuovo
+ \itindex{thread} \textit{thread} che esegue la
+ funzione di notifica specificata da
+ \var{sigev\_notify\_function} con argomento
+ \var{sigev\_value}. Se questo è diverso da
+ \val{NULL}, il \textit{thread} viene creato con
+ gli attributi specificati da
+ \var{sigev\_notify\_attribute}.\footnotemark\\
+ \const{SIGEV\_THREAD\_ID}& Invia la notifica come segnale (con le stesse
+ modalità di \const{SIGEV\_SIGNAL}) che però viene
+ recapitato al \textit{thread} indicato dal campo
+ \var{sigev\_notify\_thread\_id}. Questa modalità
+ è una estensione specifica di Linux, creata come
+ supporto per le librerie di gestione dei
+ \textit{thread}, pertanto non deve essere usata
+ da codice normale.\\
+ \hline
+ \end{tabular}
+ \caption{Valori possibili per il campo \var{sigev\_notify} in una struttura
+ \struct{sigevent}.}
+ \label{tab:sigevent_sigev_notify}
+\end{table}
+
+\footnotetext{nel caso dei \textit{timer} questa funzionalità è considerata un
+ esempio di pessima implementazione di una interfaccia, richiesta dallo
+ standard POSIX, ma da evitare totalmente, a causa della possibilità di
+ creare disservizi generando una gran quantità di processi, tanto che ne è
+ stata richiesta addirittura la rimozione.}
+
+Nel caso di \func{timer\_create} occorrerà passare alla funzione come secondo
+argomento l'indirizzo di una di queste strutture per indicare le modalità con
+cui si vuole essere notificati della scadenza del timer, se non si specifica
+nulla (passando un valore \val{NULL}) verrà inviato il segnale
+\signal{SIGALRM} al processo corrente, o per essere più precisi verrà
+utilizzato un valore equivalente all'aver specificato \const{SIGEV\_SIGNAL}
+per \var{sigev\_notify}, \signal{SIGALRM} per \var{sigev\_signo} e
+l'identificatore del timer come valore per \var{sigev\_value.sival\_int}.
+
+Il terzo argomento deve essere l'indirizzo di una variabile di tipo
+\type{timer\_t} dove sarà scritto l'identificativo associato al timer appena
+creato, da usare in tutte le successive funzioni di gestione. Una volta creato
+questo identificativo resterà univoco all'interno del processo stesso fintanto
+che il timer non viene cancellato.
+
+Si tenga presente che eventuali POSIX timer creati da un processo non vengono
+ereditati dai processi figli creati con \func{fork} e che vengono cancellati
+nella esecuzione di un programma diverso attraverso una delle funzioni
+\func{exec}. Si tenga presente inoltre che il kernel prealloca l'uso di un
+segnale \textit{real-time} per ciascun timer che viene creato con
+\func{timer\_create}; dato che ciascuno di essi richiede un posto nella coda
+dei segnali \textit{real-time}, il numero massimo di timer utilizzabili da un
+processo è limitato dalle dimensioni di detta coda, ed anche, qualora questo
+sia stato impostato, dal limite \const{RLIMIT\_SIGPENDING}.
+
+Una volta creato il timer \func{timer\_create} ed ottenuto il relativo
+identificatore, si può attivare o disattivare un allarme (in gergo
+\textsl{armare} o \textsl{disarmare} il timer) con la funzione
+\funcd{timer\_settime}, il cui prototipo è:
+\begin{functions}
+ \headdecl{signal.h}
+ \headdecl{time.h}
+
+ \funcdecl{int timer\_settime(timer\_t timerid, int flags, const struct
+ itimerspec *new\_value, struct itimerspec *old\_value)}
+
+ Arma o disarma il timer POSIX.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] all'interno di \param{new\_value.value} si è
+ specificato un tempo negativo o un numero di nanosecondi maggiore di
+ 999999999.
+ \item[\errcode{EFAULT}] si è specificato un indirizzo non valido
+ per \param{new\_value} o \param{old\_value}.
+ \end{errlist}
+}
+\end{functions}
+
+La funzione richiede che si indichi la scadenza del timer con
+l'argomento \param{new\_value}, che deve essere specificato come puntatore ad
+una struttura di tipo \struct{itimerspec}, la cui definizione è riportata in
+fig.~\ref{fig:struct_itimerspec}; se il puntatore \param{old\_value} è diverso
+da \val{NULL} il valore corrente della scadenza verrà restituito in una
+analoga struttura, ovviamente in entrambi i casi le strutture devono essere
+state allocate.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\textwidth}
+ \includestruct{listati/itimerspec.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{itimerspec}, usata per specificare la
+ scadenza di un allarme.}
+ \label{fig:struct_itimerspec}
+\end{figure}
+
+Ciascuno dei due campi di \struct{itimerspec} indica un tempo, da specificare
+con una precisione fino al nanosecondo tramite una struttura \struct{timespec}
+(la cui definizione è riportata fig.~\ref{fig:sys_timespec_struct}). Il campo
+\var{it\_value} indica la prima scadenza dell'allarme. Di default, quando il
+valore di \param{flags} è nullo, questo valore viene considerato come un
+intervallo relativo al tempo corrente,\footnote{il primo allarme scatterà cioè
+ dopo il numero di secondi e nanosecondi indicati da questo campo.} se invece
+si usa per \param{flags} il valore \const{TIMER\_ABSTIME},\footnote{al momento
+ questo è l'unico valore valido per \param{flags}.} \var{it\_value} viene
+considerato come un valore assoluto rispetto al valore usato dall'orologio a
+cui è associato il timer.\footnote{quindi a seconda dei casi lo si potrà
+ indicare o come un tempo assoluto, quando si opera rispetto all'orologio di
+ sistema (nel qual caso il valore deve essere in secondi e nanosecondi dalla
+ \textit{epoch}) o come numero di secondi o nanosecondi rispetto alla
+ partenza di un orologio di CPU, quando si opera su uno di questi.} Infine
+un valore nullo di \var{it\_value}\footnote{per nullo si intende con valori
+ nulli per entrambi i i campi \var{tv\_sec} e \var{tv\_nsec}.} può essere
+utilizzato, indipendentemente dal tipo di orologio utilizzato, per disarmare
+l'allarme.
+
+Il campo \var{it\_interval} di \struct{itimerspec} viene invece utilizzato per
+impostare un allarme periodico. Se il suo valore è nullo (se cioè sono nulli
+tutti e due i valori di detta struttura \struct{timespec}) l'allarme scatterà
+una sola volta secondo quando indicato con \var{it\_value}, altrimenti il
+valore specificato verrà preso come l'estensione del periodo di ripetizione
+della generazione dell'allarme, che proseguirà indefinitamente fintanto che
+non si disarmi il timer.
+
+Se il timer era già stato armato la funzione sovrascrive la precedente
+impostazione, se invece si indica come prima scadenza un tempo già passato,
+l'allarme verrà notificato immediatamente e al contempo verrà incrementato il
+contatore dei superamenti. Questo contatore serve a fornire una indicazione al
+programma che riceve l'allarme su un eventuale numero di scadenze che sono
+passate prima della ricezione della notifica dell'allarme.
+
+É infatti possibile, qualunque sia il meccanismo di notifica scelto, che
+quest'ultima venga ricevuta dopo che il timer è scaduto più di una
+volta.\footnote{specialmente se si imposta un timer con una ripetizione a
+ frequenza elevata.} Nel caso dell'uso di un segnale infatti il sistema mette
+in coda un solo segnale per timer,\footnote{questo indipendentemente che si
+ tratti di un segnale ordinario o \textit{real-time}; per questi ultimi
+ sarebbe anche possibile inviare un segnale per ogni scadenza, questo però
+ non viene fatto per evitare il rischio, tutt'altro che remoto, di riempire
+ la coda.} e se il sistema è sotto carico o se il segnale è bloccato, prima
+della sua ricezione può passare un intervallo di tempo sufficientemente lungo
+ad avere scadenze multiple, e lo stesso può accadere anche se si usa un
+\textit{thread} di notifica.
+
+Per questo motivo il gestore del segnale o il \textit{thread} di notifica può
+ottenere una indicazione di quante volte il timer è scaduto dall'invio della
+notifica utilizzando la funzione \funcd{timer\_getoverrun}, il cui prototipo è:
+\begin{functions}
+ \headdecl{time.h}
+
+ \funcdecl{int timer\_getoverrun(timer\_t timerid)}
+
+ Ottiene il numero di scadenze di un timer POSIX.
+
+ \bodydesc{La funzione restituisce il numero di scadenze di un timer in caso
+ di successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà
+ il valore:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] \param{timerid} non indica un timer valido.
+ \end{errlist}
+}
+\end{functions}
+
+La funzione ritorna il numero delle scadenze avvenute, che può anche essere
+nullo se non ve ne sono state. Come estensione specifica di Linux,\footnote{in
+ realtà lo standard POSIX.1-2001 prevede gli \textit{overrun} solo per i
+ segnali e non ne parla affatto in riferimento ai \textit{thread}.} quando
+si usa un segnale come meccanismo di notifica, si può ottenere direttamente
+questo valore nel campo \var{si\_overrun} della struttura \struct{siginfo\_t}
+(illustrata in fig.~\ref{fig:sig_siginfo_t}) restituita al gestore del segnale
+installato con \func{sigaction}; in questo modo non è più necessario eseguire
+successivamente una chiamata a questa funzione per ottenere il numero delle
+scadenze. Al gestore del segnale viene anche restituito, come ulteriore
+informazione, l'identificativo del timer, in questo caso nel campo
+\var{si\_timerid}.
+
+Qualora si voglia rileggere lo stato corrente di un timer, ed ottenere il
+tempo mancante ad una sua eventuale scadenza, si deve utilizzare la funzione
+\funcd{timer\_gettime}, il cui prototipo è:
+\begin{functions}
+ \headdecl{time.h}
+
+ \funcdecl{int timer\_gettime(timer\_t timerid, int flags, struct
+ itimerspec *curr\_value)}
+
+ Legge lo stato di un timer POSIX.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] \param{timerid} non indica un timer valido.
+ \item[\errcode{EFAULT}] si è specificato un indirizzo non valido
+ per \param{curr\_value}.
+ \end{errlist}
+}
+\end{functions}
+
+La funzione restituisce nella struttura \struct{itimerspec} puntata
+da \param{curr\_value} il tempo restante alla prossima scadenza nel campo
+\var{it\_value}. Questo tempo viene sempre indicato in forma relativa, anche
+nei casi in cui il timer era stato precedentemente impostato con
+\const{TIMER\_ABSTIME} indicando un tempo assoluto. Il ritorno di un valore
+nullo nel campo \var{it\_value} significa che il timer è disarmato o è
+definitivamente scaduto.
+
+Nel campo \var{it\_interval} di \param{curr\_value} viene invece restituito,
+se questo era stato impostato, il periodo di ripetizione del timer. Anche in
+questo caso il ritorno di un valore nullo significa che il timer non era stato
+impostato per una ripetizione e doveva operare, come suol dirsi, a colpo
+singolo (in gergo \textit{one shot}).
+
+Infine, quando un timer non viene più utilizzato, lo si può cancellare,
+rimuovendolo dal sistema e recuperando le relative risorse, effettuando in
+sostanza l'operazione inversa rispetto a \funcd{timer\_create}. Per questo
+compito lo standard prevede una apposita funzione \funcd{timer\_delete}, il
+cui prototipo è:
+\begin{functions}
+ \headdecl{time.h}
+
+ \funcdecl{int timer\_delete(timer\_t timerid)}
+
+ Cancella un timer POSIX.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] \param{timerid} non indica un timer valido.
+ \end{errlist}
+}
+\end{functions}