+\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
+ \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 al ritorno
+dallo stesso.
+
+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 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 \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}.
+
+\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!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. 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!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 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
+\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{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 \type{sigval\_t}.}
+ \label{fig:sig_sigval}
+\end{figure}
+
+Detto campo, identificato con il tipo di dato \type{sigval\_t}, è 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 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
+\itindex{POSIX~Timer~API} 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.
+
+Secondo lo standard POSIX la profondità della coda è indicata dalla costante
+\const{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,
+\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} 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 \itindex{thread} \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 \itindex{thread} \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.
+
+\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}
+
+% TODO: indicizzare i termini \itindex{POSIX~Timer~API} e HRT
+
+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
+\itindex{jiffies} \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
+ \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\_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}.\\
+ \hline
+ \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). Questo orologio è specifico di
+ Linux, ed è disponibile a partire dal kernel
+ 2.6.28.\\
+ \const{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.\\
+ \const{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.\\
+ \const{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 \type{clockid\_t}
+ usata per indicare a quale tipo di orologio si vuole fare riferimento.}
+ \label{tab:sig_timer_clockid_types}
+\end{table}
+
+
+% 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
+
+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}; 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}.}
+}
+
+{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}] l'indirizzo di \param{res} non è valido.
+ \item[\errcode{EINVAL}] il valore specificato per \param{clockid} non è
+ valido.
+ \end{errlist}
+}
+\end{funcproto}
+
+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.
+
+Gli orologi elencati nella seconda sezione di
+tab.~\ref{tab:sig_timer_clockid_types} sono delle estensioni specifiche di
+Linux, create per rispondere ad alcune esigenze specifiche, come quella di
+tener conto di eventuali periodi di sospensione del sistema, e presenti solo
+nelle versioni più recenti del kernel. In particolare gli ultimi due,
+contraddistinti dal suffisso \texttt{\_ALARM}, hanno un impiego particolare,
+derivato dalle esigenze emerse con Android per l'uso di Linux sui cellulari,
+che consente di creare timer che possono scattare, riattivando il sistema,
+anche quando questo è in sospensione. Per il loro utilizzo è prevista la
+necessità di una capacità specifica, \const{CAP\_WAKE\_ALARM} (vedi
+sez.~\ref{sec:proc_capabilities}).
+
+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{funcproto}{
+\fhead{time.h}
+\fdecl{int clock\_getcpuclockid(pid\_t pid, clockid\_t *clockid)}
+\fdesc{Ottiene l'identificatore dell'orologio di CPU usato da un processo.}
+}
+
+{La funzione ritorna $0$ in caso di successo ed un numero positivo per un
+ errore, nel qual caso \var{errno} assumerà uno dei 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}, avviene solo se è
+ disponibile il supporto per leggere l'orologio relativo ad un altro
+ processo.
+ \item[\errcode{ESRCH}] non esiste il processo \param{pid}.
+ \end{errlist}
+}
+\end{funcproto}
+
+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 poterla utilizzare, 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{funcproto}{
+\fhead{pthread.h}
+\fhead{time.h}
+\fdecl{int pthread\_getcpuclockid(pthread\_t thread, clockid\_t *clockid)}
+\fdesc{Ottiene l'identificatore dell'orologio di CPU associato ad un
+ \textit{thread}.}
+}
+
+{La funzione ritorna $0$ in caso di successo ed un numero positivo per un
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{ENOENT}] la funzione non è supportata dal sistema.
+ \item[\errcode{ESRCH}] non esiste il \textit{thread} identificato
+ \end{errlist}
+ }
+\end{funcproto}
+
+
+% TODO, dal 2.6.39 aggiunta clock_adjtime
+
+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, come 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à da essa previste è
+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 di sistema \funcd{timer\_create}, il cui
+prototipo è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fhead{time.h}
+\fdecl{int timer\_create(clockid\_t clockid, struct sigevent *evp,
+ timer\_t *timerid)}
+\fdesc{Crea un nuovo timer POSIX.}
+}
+
+{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}] 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{funcproto}
+
+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}; 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. Si possono inoltre utilizzare, posto di avere un kernel che li
+supporti, gli orologi aggiuntivi della seconda parte di
+tab.~\ref{tab:sig_timer_clockid_types}.
+
+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]{0.8\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}