+sez.~\ref{sec:sig_sigaction} come con \func{sigaction} sia possibile bloccare
+\signal{SIGALRM} nell'installazione dei gestori degli altri segnali, per poter
+usare l'implementazione vista in fig.~\ref{fig:sig_sleep_incomplete} senza
+interferenze. Questo però comporta una precauzione ulteriore al semplice uso
+della funzione, vediamo allora come usando la nuova interfaccia è possibile
+ottenere un'implementazione, riportata in fig.~\ref{fig:sig_sleep_ok} che non
+presenta neanche questa necessità.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/sleep.c}
+ \end{minipage}
+ \normalsize
+ \caption{Una implementazione completa di \func{sleep}.}
+ \label{fig:sig_sleep_ok}
+\end{figure}
+
+Per evitare i problemi di interferenza con gli altri segnali in questo caso
+non si è usato l'approccio di fig.~\ref{fig:sig_sleep_incomplete} evitando
+l'uso di \func{longjmp}. Come in precedenza il gestore (\texttt{\small
+ 27--30}) non esegue nessuna operazione, limitandosi a ritornare per
+interrompere il programma messo in attesa.
+
+La prima parte della funzione (\texttt{\small 6--10}) provvede ad installare
+l'opportuno gestore per \signal{SIGALRM}, salvando quello originario, che
+sarà ripristinato alla conclusione della stessa (\texttt{\small 23}); il passo
+successivo è quello di bloccare \signal{SIGALRM} (\texttt{\small 11--14}) per
+evitare che esso possa essere ricevuto dal processo fra l'esecuzione di
+\func{alarm} (\texttt{\small 16}) e la sospensione dello stesso. Nel fare
+questo si salva la maschera corrente dei segnali, che sarà ripristinata alla
+fine (\texttt{\small 22}), e al contempo si prepara la maschera dei segnali
+\var{sleep\_mask} per riattivare \signal{SIGALRM} all'esecuzione di
+\func{sigsuspend}.
+
+In questo modo non sono più possibili \textit{race condition} dato che
+\signal{SIGALRM} viene disabilitato con \func{sigprocmask} fino alla chiamata
+di \func{sigsuspend}. Questo metodo è assolutamente generale e può essere
+applicato a qualunque altra situazione in cui si deve attendere per un
+segnale, i passi sono sempre i seguenti:
+\begin{enumerate*}
+\item leggere la maschera dei segnali corrente e bloccare il segnale voluto
+ con \func{sigprocmask};
+\item mandare il processo in attesa con \func{sigsuspend} abilitando la
+ ricezione del segnale voluto;
+\item ripristinare la maschera dei segnali originaria.
+\end{enumerate*}
+Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi
+riabilitarla immediatamente dopo, in questo modo si evita il \textit{deadlock}
+dovuto all'arrivo del segnale prima dell'esecuzione di \func{sigsuspend}.
+
+\index{maschera dei segnali|)}
+
+
+\subsection{Criteri di programmazione per i gestori dei segnali}
+\label{sec:sig_signal_handler}
+
+Abbiamo finora parlato dei gestori dei segnali come funzioni chiamate in
+corrispondenza della consegna di un segnale. In realtà un gestore non può
+essere una funzione qualunque, in quanto esso può essere eseguito in
+corrispondenza all'interruzione in un punto qualunque del programma
+principale, cosa che ad esempio può rendere problematico chiamare all'interno
+di un gestore di segnali la stessa funzione che dal segnale è stata
+interrotta.
+
+\index{funzioni!\textit{signal safe}|(}
+
+Il concetto è comunque più generale e porta ad una distinzione fra quelle che
+POSIX chiama \textsl{funzioni insicure} (\textit{signal unsafe function}) e
+\textsl{funzioni sicure} (o più precisamente \textit{signal safe function}).
+Quando un segnale interrompe una funzione insicura ed il gestore chiama al suo
+interno una funzione insicura il sistema può dare luogo ad un comportamento
+indefinito, la cosa non avviene invece per le funzioni sicure.
+
+Tutto questo significa che la funzione che si usa come gestore di segnale deve
+essere programmata con molta cura per evirare questa evenienza e che non è
+possibile utilizzare al suo interno una qualunque funzione di sistema, se si
+vogliono evitare questi problemi si può ricorrere soltanto all'uso delle
+funzioni considerate sicure.
+
+L'elenco delle funzioni considerate sicure varia a seconda della
+implementazione utilizzata e dello standard a cui si fa riferimento. Non è
+riportata una lista specifica delle funzioni sicure per Linux, e si suppone
+pertanto che siano quelle richieste dallo standard. Secondo quanto richiesto
+dallo standard POSIX 1003.1 nella revisione del 2003, le ``\textit{signal safe
+ function}'' che possono essere chiamate anche all'interno di un gestore di
+segnali sono tutte quelle della lista riportata in
+fig.~\ref{fig:sig_safe_functions}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{14cm}
+ \func{\_exit}, \func{abort}, \func{accept}, \func{access},
+ \func{aio\_error} \func{aio\_return}, \func{aio\_suspend}, \func{alarm},
+ \func{bind}, \func{cfgetispeed}, \func{cfgetospeed}, \func{cfsetispeed},
+ \func{cfsetospeed}, \func{chdir}, \func{chmod}, \func{chown},
+ \func{clock\_gettime}, \func{close}, \func{connect}, \func{creat},
+ \func{dup}, \func{dup2}, \func{execle}, \func{execve}, \func{fchmod},
+ \func{fchown}, \func{fcntl}, \func{fdatasync}, \func{fork},
+ \func{fpathconf}, \func{fstat}, \func{fsync}, \func{ftruncate},
+ \func{getegid}, \func{geteuid}, \func{getgid}, \func{getgroups},
+ \func{getpeername}, \func{getpgrp}, \func{getpid}, \func{getppid},
+ \func{getsockname}, \func{getsockopt}, \func{getuid}, \func{kill},
+ \func{link}, \func{listen}, \func{lseek}, \func{lstat}, \func{mkdir},
+ \func{mkfifo}, \func{open}, \func{pathconf}, \func{pause}, \func{pipe},
+ \func{poll}, \funcm{posix\_trace\_event}, \func{pselect}, \func{raise},
+ \func{read}, \func{readlink}, \func{recv}, \func{recvfrom},
+ \func{recvmsg}, \func{rename}, \func{rmdir}, \func{select},
+ \func{sem\_post}, \func{send}, \func{sendmsg}, \func{sendto},
+ \func{setgid}, \func{setpgid}, \func{setsid}, \func{setsockopt},
+ \func{setuid}, \func{shutdown}, \func{sigaction}, \func{sigaddset},
+ \func{sigdelset}, \func{sigemptyset}, \func{sigfillset},
+ \func{sigismember}, \func{signal}, \func{sigpause}, \func{sigpending},
+ \func{sigprocmask}, \func{sigqueue}, \funcm{sigset}, \func{sigsuspend},
+ \func{sleep}, \func{socket}, \func{socketpair}, \func{stat},
+ \func{symlink}, \func{sysconf}, \func{tcdrain}, \func{tcflow},
+ \func{tcflush}, \func{tcgetattr}, \func{tcgetgrp}, \func{tcsendbreak},
+ \func{tcsetattr}, \func{tcsetpgrp}, \func{time}, \func{timer\_getoverrun},
+ \func{timer\_gettime}, \func{timer\_settime}, \func{times}, \func{umask},
+ \func{uname}, \func{unlink}, \func{utime}, \func{wait}, \func{waitpid},
+ \func{write}.
+ \end{minipage}
+ \normalsize
+ \caption{Elenco delle funzioni sicure secondo lo standard POSIX
+ 1003.1-2003.}
+ \label{fig:sig_safe_functions}
+\end{figure}
+
+\index{funzioni!\textit{signal safe}|)}
+
+Lo standard POSIX.1-2004 modifica la lista di
+fig.~\ref{fig:sig_safe_functions} aggiungendo le funzioni \func{\_Exit} e
+\func{sockatmark}, mentre lo standard POSIX.1-2008 rimuove della lista le tre
+funzioni \func{fpathconf}, \func{pathconf}, \func{sysconf} e vi aggiunge le
+ulteriori funzioni in fig.~\ref{fig:sig_safe_functions_posix_2008}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{14cm}
+ \func{execl}, \func{execv}, \func{faccessat}, \func{fchmodat},
+ \func{fchownat}, \func{fexecve}, \func{fstatat}, \func{futimens},
+ \func{linkat}, \func{mkdirat}, \func{mkfifoat}, \func{mknod},
+ \func{mknodat}, \func{openat}, \func{readlinkat}, \func{renameat},
+ \func{symlinkat}, \func{unlinkat}, \func{utimensat}, \func{utimes}.
+ \end{minipage}
+ \normalsize
+ \caption{Ulteriori funzioni sicure secondo lo standard POSIX.1-2008.}
+ \label{fig:sig_safe_functions_posix_2008}
+\end{figure}
+
+
+Per questo motivo è opportuno mantenere al minimo indispensabile le operazioni
+effettuate all'interno di un gestore di segnali, qualora si debbano compiere
+operazioni complesse è sempre preferibile utilizzare la tecnica in cui si usa
+il gestore per impostare il valore di una qualche variabile globale, e poi si
+eseguono le operazioni complesse nel programma verificando (con tutti gli
+accorgimenti visti in precedenza) il valore di questa variabile tutte le volte
+che si è rilevata una interruzione dovuta ad un segnale.
+
+
+\section{Funzionalità avanzate}
+\label{sec:sig_advanced_signal}
+
+Tratteremo in questa ultima sezione alcune funzionalità avanzate relativa ai
+segnali ed in generale ai meccanismi di notifica, a partire dalla funzioni
+introdotte per la gestione dei cosiddetti ``\textsl{segnali real-time}'', alla
+gestione avanzata delle temporizzazioni e le nuove interfacce per la gestione
+di segnali ed eventi attraverso l'uso di file descriptor.
+
+\subsection{I segnali \textit{real-time}}
+\label{sec:sig_real_time}
+
+Lo standard POSIX.1b, nel definire una serie di nuove interfacce per i servizi
+\textit{real-time}, ha introdotto una estensione del modello classico dei
+segnali che presenta dei significativi miglioramenti,\footnote{questa
+ estensione è stata introdotta in Linux a partire dal kernel 2.1.43, e dalla
+ versione 2.1 della \acr{glibc}.} in particolare sono stati superati tre
+limiti fondamentali dei segnali classici:
+\begin{basedescript}{\desclabelwidth{1cm}\desclabelstyle{\nextlinelabel}}
+\item[\textbf{I segnali non sono accumulati}]
+ se più segnali vengono generati prima dell'esecuzione di un gestore
+ questo sarà eseguito una sola volta, ed il processo non sarà in grado di
+ accorgersi di quante volte l'evento che ha generato il segnale è accaduto.
+\item[\textbf{I segnali non trasportano informazione}]
+ i segnali classici non prevedono altra informazione sull'evento
+ che li ha generati se non il fatto che sono stati emessi (tutta
+ l'informazione che il kernel associa ad un segnale è il suo numero).
+\item[\textbf{I segnali non hanno un ordine di consegna}]
+ l'ordine in cui diversi segnali vengono consegnati è casuale e non
+ prevedibile. Non è possibile stabilire una priorità per cui la reazione a
+ certi segnali ha la precedenza rispetto ad altri.
+\end{basedescript}
+
+Per poter superare queste limitazioni lo standard POSIX.1b ha introdotto delle
+nuove caratteristiche, che sono state associate ad una nuova classe di
+segnali, che vengono chiamati \textsl{segnali real-time}, in particolare le
+funzionalità aggiunte sono:
+
+\begin{enumerate}
+\item i segnali sono inseriti in una coda che permette di consegnare istanze
+ multiple dello stesso segnale qualora esso venga inviato più volte prima
+ dell'esecuzione del gestore; si assicura così che il processo riceva un
+ segnale per ogni occorrenza dell'evento che lo genera;
+\item è stata introdotta una priorità nella consegna dei segnali: i segnali
+ vengono consegnati in ordine a seconda del loro valore, partendo da quelli
+ con un numero minore, che pertanto hanno una priorità maggiore;
+\item è stata introdotta la possibilità di restituire dei dati al gestore,
+ attraverso l'uso di un apposito campo \var{si\_value} nella struttura
+ \struct{siginfo\_t}, accessibile tramite gestori di tipo
+ \var{sa\_sigaction}.
+\end{enumerate}
+
+Tutte queste nuove funzionalità eccetto l'ultima, che, come illustrato in
+sez.~\ref{sec:sig_sigaction}, è disponibile anche con i segnali ordinari, si
+applicano solo ai nuovi segnali \textit{real-time}; questi ultimi sono
+accessibili in un intervallo di valori specificati dalle due costanti
+\constd{SIGRTMIN} e \constd{SIGRTMAX}, che specificano il numero minimo e
+massimo associato ad un segnale \textit{real-time}.
+
+Su Linux di solito il primo valore è 33, mentre il secondo è \code{\_NSIG-1},
+che di norma (vale a dire sulla piattaforma i386) è 64. Questo dà un totale di
+32 segnali disponibili, contro gli almeno 8 richiesti da POSIX.1b. Si tenga
+presente però che i primi segnali \textit{real-time} disponibili vengono usati
+dalla \acr{glibc} per l'implementazione dei \textit{thread} POSIX (vedi
+sez.~\ref{sec:thread_posix_intro}), ed il valore di \const{SIGRTMIN} viene
+modificato di conseguenza.\footnote{per la precisione vengono usati i primi
+ tre per la vecchia implementazione dei \textit{LinuxThread} ed i primi due
+ per la nuova NTPL (\textit{New Thread Posix Library}), il che comporta che
+ \const{SIGRTMIN} a seconda dei casi può assumere i valori 34 o 35.}
+
+Per questo motivo nei programmi che usano i segnali \textit{real-time} non si
+deve mai usare un valore assoluto dato che si correrebbe il rischio di
+utilizzare un segnale in uso alle librerie, ed il numero del segnale deve
+invece essere sempre specificato in forma relativa a \const{SIGRTMIN} (come
+\code{SIGRTMIN + n}) avendo inoltre cura di controllare di non aver mai
+superato \const{SIGRTMAX}.
+
+I segnali con un numero più basso hanno una priorità maggiore e vengono
+consegnati per primi, inoltre i segnali \textit{real-time} non possono
+interrompere l'esecuzione di un gestore di un segnale a priorità più alta; la
+loro azione predefinita è quella di terminare il programma. I segnali
+ordinari hanno tutti la stessa priorità, che è più alta di quella di qualunque
+segnale \textit{real-time}. Lo standard non definisce niente al riguardo ma
+Linux, come molte altre implementazioni, adotta questa politica.
+
+Si tenga presente che questi nuovi segnali non sono associati a nessun evento
+specifico, a meno di non richiedere specificamente il loro utilizzo in
+meccanismi di notifica come quelli per l'I/O asincrono (vedi
+sez.~\ref{sec:file_asyncronous_io}) o per le code di messaggi POSIX (vedi
+sez.~\ref{sec:ipc_posix_mq}), pertanto devono essere inviati esplicitamente.
+
+Inoltre, per poter usufruire della capacità di restituire dei dati, i relativi
+gestori devono essere installati con \func{sigaction}, specificando per
+\var{sa\_flags} la modalità \const{SA\_SIGINFO} che permette di utilizzare la
+forma estesa \var{sa\_sigaction} del gestore (vedi
+sez.~\ref{sec:sig_sigaction}). In questo modo tutti i segnali
+\textit{real-time} possono restituire al gestore una serie di informazioni
+aggiuntive attraverso l'argomento \struct{siginfo\_t}, la cui definizione è
+stata già vista in fig.~\ref{fig:sig_siginfo_t}, nella trattazione dei gestori
+in forma estesa.
+
+In particolare i campi utilizzati dai segnali \textit{real-time} sono
+\var{si\_pid} e \var{si\_uid} in cui vengono memorizzati rispettivamente il
+\ids{PID} e l'\ids{UID} effettivo del processo che ha inviato il segnale,
+mentre per la restituzione dei dati viene usato il campo \var{si\_value}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/sigval_t.h}
+ \end{minipage}
+ \normalsize
+ \caption{La definizione dell'unione \structd{sigval}, definita anche come
+ tipo \typed{sigval\_t}.}
+ \label{fig:sig_sigval}
+\end{figure}
+
+Detto campo, identificato con il tipo di dato \type{sigval\_t}, è una
+\dirct{union} di tipo \struct{sigval} (la sua definizione è in
+fig.~\ref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico,
+se usata nella forma \var{sival\_int}, o un puntatore, se usata nella forma
+\var{sival\_ptr}. L'unione viene usata dai segnali \textit{real-time} e da
+vari meccanismi di notifica per restituire dati al gestore del segnale in
+\var{si\_value}. Un campo di tipo \type{sigval\_t} è presente anche nella
+struttura \struct{sigevent} (definita in fig.~\ref{fig:struct_sigevent}) che
+viene usata dai meccanismi di notifica come quelli per i timer POSIX (vedi
+sez.~\ref{sec:sig_timer_adv}), l'I/O asincrono (vedi
+sez.~\ref{sec:file_asyncronous_io}) o le code di messaggi POSIX (vedi
+sez.~\ref{sec:ipc_posix_mq}).
+
+A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
+inviare segnali \textit{real-time}, poiché non è in grado di fornire alcun
+valore per il campo \var{si\_value} restituito nella struttura
+\struct{siginfo\_t} prevista da un gestore in forma estesa. Per questo motivo
+lo standard ha previsto una nuova funzione, \funcd{sigqueue}, il cui prototipo
+è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigqueue(pid\_t pid, int signo, const union sigval value)}
+\fdesc{Invia un segnale con un valore di informazione.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EAGAIN}] la coda è esaurita, ci sono già
+ \const{SIGQUEUE\_MAX} segnali in attesa si consegna.
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per
+ \param{signo}.
+ \item[\errcode{EPERM}] non si hanno privilegi appropriati per inviare il
+ segnale al processo specificato.
+ \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
+ \end{errlist}
+}
+\end{funcproto}
+
+
+La funzione invia il segnale indicato dall'argomento \param{signo} al processo
+indicato dall'argomento \param{pid}. Per il resto il comportamento della
+funzione è analogo a quello di \func{kill}, ed i privilegi occorrenti ad
+inviare il segnale ad un determinato processo sono gli stessi; un valore nullo
+di \param{signo} permette di verificare le condizioni di errore senza inviare
+nessun segnale.
+
+Se il segnale è bloccato la funzione ritorna immediatamente, se si è
+installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili,
+(vale a dire che c'è posto nella coda dei segnali \textit{real-time}) esso
+viene inserito e diventa pendente. Una volta consegnato il segnale il gestore
+otterrà nel campo \var{si\_code} di \struct{siginfo\_t} il valore
+\const{SI\_QUEUE} e nel campo \var{si\_value} il valore indicato
+nell'argomento \param{value}. Se invece si è installato un gestore nella forma
+classica il segnale sarà generato, ma tutte le caratteristiche tipiche dei
+segnali \textit{real-time} (priorità e coda) saranno perse.
+
+Per lo standard POSIX la profondità della coda è indicata dalla costante
+\constd{SIGQUEUE\_MAX}, una della tante costanti di sistema definite dallo
+standard POSIX che non abbiamo riportato esplicitamente in
+sez.~\ref{sec:sys_limits}. Il suo valore minimo secondo lo standard,
+\macrod{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux la coda ha una
+dimensione variabile; fino alla versione 2.6.7 c'era un limite massimo globale
+che poteva essere impostato come parametro del kernel in
+\sysctlfiled{kernel/rtsig-max} ed il valore predefinito era pari a 1024. A
+partire dal kernel 2.6.8 il valore globale è stato rimosso e sostituito dalla
+risorsa \const{RLIMIT\_SIGPENDING} associata al singolo utente, che può essere
+modificata con \func{setrlimit} come illustrato in
+sez.~\ref{sec:sys_resource_limit}.
+
+Lo standard POSIX.1b definisce inoltre delle nuove funzioni di sistema che
+permettono di gestire l'attesa di segnali specifici su una coda, esse servono
+in particolar modo nel caso dei \textit{thread}, in cui si possono usare i
+segnali \textit{real-time} come meccanismi di comunicazione elementare; la
+prima di queste è \funcd{sigwait}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigwait(const sigset\_t *set, int *sig)}
+\fdesc{Attende la ricezione di un segnale.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINTR}] la funzione è stata interrotta.
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per
+ \end{errlist}
+ ed inoltre \errval{EFAULT} nel suo significato generico.}
+\end{funcproto}
+
+La funzione estrae dall'insieme dei segnali pendenti uno qualunque fra quelli
+indicati nel \textit{signal set} specificato in \param{set}, il cui valore
+viene restituito nella variabile puntata da \param{sig}. Se sono pendenti più
+segnali, viene estratto quello a priorità più alta, cioè quello con il numero
+più basso. Se, nel caso di segnali \textit{real-time}, c'è più di un segnale
+pendente, ne verrà estratto solo uno. Una volta estratto il segnale non verrà
+più consegnato, e se era in una coda il suo posto sarà liberato. Se non c'è
+nessun segnale pendente il processo viene bloccato fintanto che non ne arriva
+uno.
+
+Per un funzionamento corretto la funzione richiede che alla sua chiamata i
+segnali di \param{set} siano bloccati. In caso contrario si avrebbe un
+conflitto con gli eventuali gestori: pertanto non si deve utilizzare per
+lo stesso segnale questa funzione e \func{sigaction}. Se questo non avviene il
+comportamento del sistema è indeterminato: il segnale può sia essere
+consegnato che essere ricevuto da \func{sigwait}, il tutto in maniera non
+prevedibile.
+
+Lo standard POSIX.1b definisce altre due funzioni di sistema, anch'esse usate
+prevalentemente con i \textit{thread}; \funcd{sigwaitinfo} e
+\funcd{sigtimedwait}, i relativi prototipi sono:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigwaitinfo(const sigset\_t *set, siginfo\_t *info)}
+\fdesc{Attende un segnale con le relative informazioni.}
+\fdecl{int sigtimedwait(const sigset\_t *set, siginfo\_t *info, const
+ struct timespec *timeout)}
+\fdesc{Attende un segnale con le relative informazioni per un tempo massimo.}
+}
+
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno gli stessi valori di \func{sigwait} ai quali
+ si aggiunge per \func{sigtimedwait}:
+ \begin{errlist}
+ \item[\errcode{EAGAIN}] si è superato il timeout senza che un segnale atteso
+ sia stato ricevuto.
+ \end{errlist}
+}
+\end{funcproto}
+
+
+Entrambe le funzioni sono estensioni di \func{sigwait}. La prima permette di
+ricevere, oltre al numero del segnale, anche le informazioni ad esso associate
+tramite l'argomento \param{info}; in particolare viene restituito il numero
+del segnale nel campo \var{si\_signo}, la sua causa in \var{si\_code}, e se il
+segnale è stato immesso sulla coda con \func{sigqueue}, il valore di ritorno
+ad esso associato viene riportato in \var{si\_value}, che altrimenti è
+indefinito.
+
+La seconda è identica alla prima ma in più permette di specificare un timeout
+con l'argomento omonimo, scaduto il quale ritornerà con un errore. Se si
+specifica per \param{timeout} un puntatore nullo il comportamento sarà
+identico a \func{sigwaitinfo}. Se si specifica un tempo di timeout nullo e non
+ci sono segnali pendenti la funzione ritornerà immediatamente, in questo modo
+si può eliminare un segnale dalla coda senza dover essere bloccati qualora
+esso non sia presente.
+
+L'uso di queste funzioni è principalmente associato alla gestione dei segnali
+con i \textit{thread}. In genere esse vengono chiamate dal \textit{thread}
+incaricato della gestione, che al ritorno della funzione esegue il codice che
+usualmente sarebbe messo nel gestore, per poi ripetere la chiamata per
+mettersi in attesa del segnale successivo. Questo ovviamente comporta che non
+devono essere installati gestori, che solo il \textit{thread} di gestione deve
+usare \func{sigwait} e che i segnali gestiti in questa maniera, per evitare
+che venga eseguita l'azione predefinita, devono essere mascherati per tutti i
+\textit{thread}, compreso quello dedicato alla gestione, che potrebbe
+riceverlo fra due chiamate successive.
+
+
+\subsection{La gestione avanzata delle temporizzazioni}
+\label{sec:sig_timer_adv}
+
+Sia le funzioni per la gestione dei tempi viste in
+sez.~\ref{sec:sys_cpu_times} che quelle per la gestione dei timer di
+sez.~\ref{sec:sig_alarm_abort} sono state a lungo limitate dalla risoluzione
+massima dei tempi dell'orologio interno del kernel, che era quella ottenibile
+dal timer di sistema che governa lo \textit{scheduler}, e quindi limitate
+dalla frequenza dello stesso che si ricordi, come già illustrato in
+sez.~\ref{sec:proc_hierarchy}, è data dal valore della costante \texttt{HZ}.
+
+I contatori usati per il calcolo dei tempi infatti erano basati sul numero di
+\textit{jiffies} che vengono incrementati ad ogni \textit{clock tick} del
+timer di sistema, il che comportava anche, come accennato in
+sez.~\ref{sec:sig_alarm_abort} per \func{setitimer}, problemi per il massimo
+periodo di tempo copribile da alcuni di questi orologi, come quelli associati
+al \textit{process time} almeno fino a quando, con il kernel 2.6.16, non è
+stato rimosso il limite di un valore a 32 bit per i \textit{jiffies}.
+
+\itindbeg{POSIX~Timer~API}
+
+Nelle architetture moderne però tutti i computer sono dotati di temporizzatori
+hardware che possono supportare risoluzioni molto elevate, ed in maniera del
+tutto indipendente dalla frequenza scelta per il timer di sistema che governa
+lo \textit{scheduler}, normalmente si possono ottenere precisioni fino al
+microsecondo, andando molto oltre in caso di hardware dedicato.
+
+Per questo lo standard POSIX.1-2001 ha previsto una serie di nuove funzioni
+relative a quelli che vengono chiamati ``\textsl{orologi}
+\textit{real-time}'', in grado di supportare risoluzioni fino al
+nanosecondo. Inoltre le CPU più moderne sono dotate a loro volta di contatori
+ad alta definizione che consentono una grande accuratezza nella misura del
+tempo da esse dedicato all'esecuzione di un processo.
+
+Per usare queste funzionalità ed ottenere risoluzioni temporali più accurate,
+occorre però un opportuno supporto da parte del kernel, ed i cosiddetti
+\itindex{High~Resolution~Timer~(HRT)} \textit{high resolution timer} che
+consentono di fare ciò sono stati introdotti nel kernel ufficiale solo a
+partire dalla versione 2.6.21.\footnote{per il supporto deve essere stata
+ abilitata l'opzione di compilazione \texttt{CONFIG\_HIGH\_RES\_TIMERS}, il
+ supporto era però disponibile anche in precedenza nei patch facenti parte
+ dello sviluppo delle estensioni \textit{real-time} del kernel, per cui
+ alcune distribuzioni possono averlo anche con versioni precedenti del
+ kernel.} Le funzioni definite dallo standard POSIX per gestire orologi ad
+alta definizione però erano già presenti, essendo stata introdotte insieme ad
+altre funzioni per il supporto delle estensioni \textit{real-time} con il
+rilascio del kernel 2.6, ma la risoluzione effettiva era nominale.
+
+A tutte le implementazioni che si rifanno a queste estensioni è richiesto di
+disporre di una versione \textit{real-time} almeno per l'orologio generale di
+sistema, quello che mantiene il \textit{calendar time} (vedi
+sez.~\ref{sec:sys_time_base}), che in questa forma deve indicare il numero di
+secondi e nanosecondi passati a partire dal primo gennaio 1970 (\textit{The
+ Epoch}). Si ricordi infatti che l'orologio ordinario usato dal
+\textit{calendar time} riporta solo un numero di secondi, e che la risoluzione
+effettiva normalmente non raggiunge il nanosecondo (a meno di hardware
+specializzato). Oltre all'orologio generale di sistema possono essere
+presenti altri tipi di orologi \textit{real-time}, ciascuno dei quali viene
+identificato da un opportuno valore di una variabile di tipo
+\type{clockid\_t}; un elenco di quelli disponibili su Linux è riportato in
+tab.~\ref{tab:sig_timer_clockid_types}.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{CLOCK\_REALTIME} & Orologio \textit{real-time} di sistema, può
+ essere impostato solo con privilegi
+ amministrativi.\\
+ \constd{CLOCK\_MONOTONIC} & Orologio che indica un tempo monotono
+ crescente (a partire da un tempo iniziale non
+ specificato) che non può essere modificato e
+ non cambia neanche in caso di reimpostazione
+ dell'orologio di sistema.\\
+ \constd{CLOCK\_PROCESS\_CPUTIME\_ID}& Contatore del tempo di CPU usato
+ da un processo (il \textit{process time} di
+ sez.~\ref{sec:sys_cpu_times}, nel totale di
+ \textit{system time} e \textit{user time})
+ comprensivo di tutto il tempo di CPU usato
+ da eventuali \textit{thread}.\\
+ \constd{CLOCK\_THREAD\_CPUTIME\_ID}& Contatore del tempo di CPU
+ (\textit{user time} e \textit{system time})
+ usato da un singolo \textit{thread}.\\
+ \hline
+ \constd{CLOCK\_MONOTONIC\_RAW}&Simile al precedente, ma non subisce gli
+ aggiustamenti dovuti all'uso di NTP (viene
+ usato per fare riferimento ad una fonte
+ hardware). Questo orologio è specifico di
+ Linux, ed è disponibile a partire dal kernel
+ 2.6.28.\\
+ \constd{CLOCK\_BOOTTIME} & Identico a \const{CLOCK\_MONOTONIC} ma tiene
+ conto anche del tempo durante il quale il
+ sistema è stato sospeso (nel caso di
+ sospensione in RAM o \textsl{ibernazione} su
+ disco. Questo orologio è specifico di Linux,
+ ed è disponibile a partire dal kernel
+ 2.6.39.\\
+ \constd{CLOCK\_REALTIME\_ALARM}&Identico a \const{CLOCK\_REALTIME}, ma se
+ usato per un timer il sistema sarà riattivato
+ anche se è in sospensione. Questo orologio è
+ specifico di Linux, ed è disponibile a
+ partire dal kernel 3.0.\\
+ \constd{CLOCK\_BOOTTIME\_ALARM}&Identico a \const{CLOCK\_BOOTTIME}, ma se
+ usato per un timer il sistema sarà riattivato
+ anche se è in sospensione. Questo orologio è
+ specifico di Linux, ed è disponibile a
+ partire dal kernel 3.0.\\
+% \const{} & .\\
+ \hline
+ \end{tabular}
+ \caption{Valori possibili per una variabile di tipo \typed{clockid\_t}
+ usata per indicare a quale tipo di orologio si vuole fare riferimento.}
+ \label{tab:sig_timer_clockid_types}
+\end{table}
+
+
+% TODO: dal 4.17 CLOCK_MONOTONIC e CLOCK_BOOTTIME sono identici vedi
+% https://lwn.net/Articles/751651/ e
+% https://git.kernel.org/linus/d6ed449afdb38f89a7b38ec50e367559e1b8f71f
+% change reverted, vedi: https://lwn.net/Articles/752757/
+
+% NOTE: dal 3.0 anche i cosiddetti Posix Alarm Timers, con
+% CLOCK_REALTIME_ALARM vedi http://lwn.net/Articles/429925/
+% TODO: dal 3.10 anche CLOCK_TAI
+
+% TODO seguire l'evoluzione delle nuove syscall per il problema del 2038,
+% iniziate ad entrare nel kernel dal 5.1, vedi
+% https://lwn.net/Articles/776435/, https://lwn.net/Articles/782511/,
+% https://git.kernel.org/linus/b1b988a6a035
+
+Per poter utilizzare queste funzionalità la \acr{glibc} richiede che la
+macro \macro{\_POSIX\_C\_SOURCE} sia definita ad un valore maggiore o uguale
+di \texttt{199309L} (vedi sez.~\ref{sec:intro_gcc_glibc_std}), inoltre i
+programmi che le usano devono essere collegati con la libreria delle
+estensioni \textit{real-time} usando esplicitamente l'opzione \texttt{-lrt}.
+
+Si tenga presente inoltre che la disponibilità di queste funzionalità avanzate
+può essere controllato dalla definizione della macro \macrod{\_POSIX\_TIMERS}
+ad un valore maggiore di 0, e che le ulteriori macro
+\macrod{\_POSIX\_MONOTONIC\_CLOCK}, \macrod{\_POSIX\_CPUTIME} e
+\macrod{\_POSIX\_THREAD\_CPUTIME} indicano la presenza dei rispettivi orologi
+di tipo \const{CLOCK\_MONOTONIC}, \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
+\const{CLOCK\_THREAD\_CPUTIME\_ID}; tutte queste macro sono definite in
+\headfile{unistd.h}, che pertanto deve essere incluso per poterle
+controllarle. Infine se il kernel ha il supporto per gli \textit{high
+ resolution timer} un elenco degli orologi e dei timer può essere ottenuto
+tramite il file \procfile{/proc/timer\_list}.
+
+Le due funzioni che ci consentono rispettivamente di modificare o leggere il
+valore per uno degli orologi \textit{real-time} sono \funcd{clock\_settime} e
+\funcd{clock\_gettime}; i rispettivi prototipi sono:
+
+\begin{funcproto}{
+\fhead{time.h}
+\fdecl{int clock\_settime(clockid\_t clockid, const struct timespec *tp)}
+\fdesc{Imposta un orologio \textit{real-time}.}
+\fdecl{int clock\_gettime(clockid\_t clockid, struct timespec *tp)}
+\fdesc{Legge un orologio \textit{real-time}.}
+}
+
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EFAULT}] l'indirizzo \param{tp} non è valido.
+ \item[\errcode{EINVAL}] il valore specificato per \param{clockid} non è
+ valido o il relativo orologio \textit{real-time} non è supportato dal
+ sistema.
+ \item[\errcode{EPERM}] non si ha il permesso di impostare l'orologio
+ indicato (solo per \func{clock\_settime}).
+ \end{errlist}
+}
+\end{funcproto}
+
+Entrambe le funzioni richiedono che si specifichi come primo argomento il tipo
+di orologio su cui si vuole operare con uno dei valori di
+tab.~\ref{tab:sig_timer_clockid_types} o con il risultato di una chiamata a
+\func{clock\_getcpuclockid} (che tratteremo a breve), il secondo argomento
+invece è sempre il puntatore \param{tp} ad una struttura \struct{timespec}
+(vedi fig.~\ref{fig:sys_timespec_struct}) che deve essere stata
+precedentemente allocata. Per \func{clock\_settime} questa dovrà anche essere
+stata inizializzata con il valore che si vuole impostare sull'orologio, mentre
+per \func{clock\_gettime} verrà restituito al suo interno il valore corrente
+dello stesso.
+
+Si tenga presente inoltre che per eseguire un cambiamento sull'orologio
+generale di sistema \const{CLOCK\_REALTIME} occorrono i privilegi
+amministrativi;\footnote{ed in particolare la \textit{capability}
+ \const{CAP\_SYS\_TIME}.} inoltre ogni cambiamento ad esso apportato non avrà
+nessun effetto sulle temporizzazioni effettuate in forma relativa, come quelle
+impostate sulle quantità di \textit{process time} o per un intervallo di tempo
+da trascorrere, ma solo su quelle che hanno richiesto una temporizzazione ad
+un istante preciso (in termini di \textit{calendar time}). Si tenga inoltre
+presente che nel caso di Linux \const{CLOCK\_REALTIME} è l'unico orologio per
+cui si può effettuare una modifica, infatti nonostante lo standard preveda la
+possibilità di modifiche anche per \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
+\const{CLOCK\_THREAD\_CPUTIME\_ID}, il kernel non le consente.
+
+Oltre alle due funzioni precedenti, lo standard POSIX prevede una terza
+funzione di sistema che consenta di ottenere la risoluzione effettiva fornita
+da un certo orologio, la funzione è \funcd{clock\_getres} ed il suo prototipo
+è:
+
+\begin{funcproto}{
+\fhead{time.h}
+\fdecl{int clock\_getres(clockid\_t clockid, struct timespec *res)}
+\fdesc{Legge la risoluzione di un orologio \textit{real-time}.}
+}