+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}.}
+}
+
+{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}
+
+La struttura \struct{sigevent} (accessibile includendo \headfile{time.h}) è
+riportata in fig.~\ref{fig:struct_sigevent}, 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
+ \constd{SIGEV\_NONE} & Non viene inviata nessuna notifica.\\
+ \constd{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
+ \dirct{union} \texttt{sigval}, la cui definizione
+ è in fig.~\ref{fig:sig_sigval}) come valore del
+ campo \var{si\_value} di \struct{siginfo\_t}.\\
+ \constd{SIGEV\_THREAD} & La notifica viene effettuata creando un nuovo
+ \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\\
+ \constd{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 nell'uso ordinario, 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
+\typed{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 di sistema
+\funcd{timer\_settime}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fhead{time.h}
+\fdecl{int timer\_settime(timer\_t timerid, int flags, const struct
+ itimerspec *new\_value, struct itimerspec *old\_value)}
+\fdesc{Arma o disarma un 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{EFAULT}] si è specificato un indirizzo non valido
+ per \param{new\_value} o \param{old\_value}.
+ \item[\errcode{EINVAL}] all'interno di \param{new\_value.value} si è
+ specificato un tempo negativo o un numero di nanosecondi maggiore di
+ 999999999.
+ \end{errlist}
+}
+\end{funcproto}
+
+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]{0.8\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, 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 \constd{TIMER\_ABSTIME}, che al momento è l'unico
+valore valido per \param{flags}, allora \var{it\_value} viene considerato come
+un valore assoluto rispetto al valore usato dall'orologio a cui è associato il
+timer.
+
+Quindi a seconda dei casi si potrà impostare un timer o con 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 con un 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}, dove per
+nullo si intende con valori nulli per entrambi 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 due campi \var{tv\_sec} e \var{tv\_nsec} di detta struttura
+\struct{timespec}, l'allarme scatterà una sola volta secondo quando indicato
+con \var{it\_value}, altrimenti il valore specificato nella struttura 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,
+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 di sistema \funcd{timer\_getoverrun}, il cui
+prototipo è:
+
+\begin{funcproto}{
+\fhead{time.h}
+\fdecl{int timer\_getoverrun(timer\_t timerid)}
+\fdesc{Ottiene il numero di scadenze di un timer POSIX.}
+}
+
+{La funzione ritorna il numero di scadenze di un timer in caso di successo e
+ $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] \param{timerid} non indica un timer valido.
+ \end{errlist}
+}
+\end{funcproto}
+
+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
+di sistema \funcd{timer\_gettime}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{time.h}
+\fdecl{int timer\_gettime(timer\_t timerid, int flags, struct
+ itimerspec *curr\_value)}
+\fdesc{Legge lo stato di un 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{EFAULT}] si è specificato un indirizzo non valido
+ per \param{curr\_value}.
+ \item[\errcode{EINVAL}] \param{timerid} non indica un timer valido.
+ \end{errlist}
+}
+\end{funcproto}
+
+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 \func{timer\_create}. Per questo
+compito lo standard prevede una apposita funzione di sistema,
+\funcd{timer\_delete}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{time.h}
+\fdecl{int timer\_delete(timer\_t timerid)}
+\fdesc{Cancella un 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{EINVAL}] \param{timerid} non indica un timer valido.
+ \end{errlist}
+}
+\end{funcproto}
+
+La funzione elimina il timer identificato da \param{timerid}, disarmandolo se
+questo era stato attivato. Nel caso, poco probabile ma comunque possibile, che
+un timer venga cancellato prima della ricezione del segnale pendente per la
+notifica di una scadenza, il comportamento del sistema è indefinito.
+
+Infine a partire dal kernel 2.6 e per le versioni della \acr{libc} superiori
+alla 2.1, si può utilizzare la nuova interfaccia dei timer POSIX anche per le
+funzioni di attesa, per questo è disponibile la funzione di sistema
+\funcd{clock\_nanosleep}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{time.h}
+\fdecl{int clock\_nanosleep(clockid\_t clock\_id, int flags, const struct
+ timespec *request,\\
+\phantom{int clock\_nanosleep(}struct timespec *remain)}
+\fdesc{Pone il processo in pausa per un tempo specificato.}
+}
+
+{La funzione ritorna $0$ in caso di successo ed un valore positivo per un
+ errore, espresso dai valori:
+ \begin{errlist}
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINVAL}] si è specificato un numero di secondi negativo o
+ un numero di nanosecondi maggiore di 999.999.999 o indicato un orologio
+ non valido.
+ \end{errlist}
+ ed inoltre \errval{EFAULT} nel suo significato generico.}
+\end{funcproto}
+
+I due argomenti \param{request} e \param{remain} sono identici agli analoghi di
+\func{nanosleep} che abbiamo visto in sez.~\ref{sec:sig_pause_sleep}, ed hanno
+lo stesso significato. L'argomento \param{clock\_id} consente di indicare
+quale orologio si intende utilizzare per l'attesa con uno dei valori della
+prima parte di tab.~\ref{tab:sig_timer_clockid_types} (eccetto
+\const{CLOCK\_THREAD\_CPUTIME\_ID}). L'argomento \param{flags} consente di
+modificare il comportamento della funzione, il suo unico valore valido al
+momento è \const{TIMER\_ABSTIME} che, come per \func{timer\_settime} indica di
+considerare il tempo indicato in \param{request} come assoluto anziché
+relativo.
+
+Il comportamento della funzione è analogo a \func{nanosleep}, se la chiamata
+viene interrotta il tempo rimanente viene restituito in \param{remain}.
+Utilizzata normalmente con attese relative può soffrire degli stessi problemi
+di deriva di cui si è parlato in sez.~\ref{sec:sig_pause_sleep} dovuti ad
+interruzioni ripetute per via degli arrotondamenti fatti a questo tempo. Ma
+grazie alla possibilità di specificare tempi assoluti con \param{flags} si può
+ovviare a questo problema ricavando il tempo corrente con
+\func{clock\_gettime}, aggiungendovi l'intervallo di attesa, ed impostando
+questa come tempo assoluto.
+
+Si tenga presente che se si è usato il valore \const{TIMER\_ABSTIME}
+per \param{flags} e si è indicato un tempo assoluto che è già passato la
+funzione ritorna immediatamente senza nessuna sospensione. In caso di
+interruzione da parte di un segnale il tempo rimanente viene restituito
+in \param{remain} soltanto se questo non è un puntatore \val{NULL} e non si è
+specificato \const{TIMER\_ABSTIME} per \param{flags}.
+
+
+\itindend{POSIX~Timer~API}
+
+
+\subsection{Ulteriori funzioni di gestione}
+\label{sec:sig_specific_features}
+
+In questo ultimo paragrafo esamineremo le rimanenti funzioni di gestione dei
+segnali non descritte finora, relative agli aspetti meno utilizzati e più
+``\textsl{esoterici}'' della interfaccia.
+
+La prima di queste funzioni è la funzione di sistema \funcd{sigpending},
+anch'essa introdotta dallo standard POSIX.1, il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigpending(sigset\_t *set)}
+\fdesc{Legge l'insieme dei segnali pendenti.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà solo il valore \errcode{EFAULT} nel suo
+ significato generico.}
+\end{funcproto}
+
+La funzione permette di ricavare quali sono i segnali pendenti per il processo
+in corso, cioè i segnali che sono stati inviati dal kernel ma non sono stati
+ancora ricevuti dal processo in quanto bloccati. Non esiste una funzione
+equivalente nella vecchia interfaccia, ma essa è tutto sommato poco utile,
+dato che essa può solo assicurare che un segnale è stato inviato, dato che
+escluderne l'avvenuto invio al momento della chiamata non significa nulla
+rispetto a quanto potrebbe essere in un qualunque momento successivo.
+
+Una delle caratteristiche di BSD, disponibile anche in Linux, è la possibilità
+di usare uno \textit{stack} alternativo per i segnali; è cioè possibile fare
+usare al sistema un altro \textit{stack} (invece di quello relativo al
+processo, vedi sez.~\ref{sec:proc_mem_layout}) solo durante l'esecuzione di un
+gestore. L'uso di uno \textit{stack} alternativo è del tutto trasparente ai
+gestori, occorre però seguire una certa procedura:
+\begin{enumerate*}
+\item allocare un'area di memoria di dimensione sufficiente da usare come
+ \textit{stack} alternativo;
+\item usare la funzione \func{sigaltstack} per rendere noto al sistema
+ l'esistenza e la locazione dello \textit{stack} alternativo;
+\item quando si installa un gestore occorre usare \func{sigaction}
+ specificando il flag \const{SA\_ONSTACK} (vedi tab.~\ref{tab:sig_sa_flag})
+ per dire al sistema di usare lo \textit{stack} alternativo durante
+ l'esecuzione del gestore.
+\end{enumerate*}
+
+In genere il primo passo viene effettuato allocando un'opportuna area di
+memoria con \code{malloc}; in \headfile{signal.h} sono definite due costanti,
+\constd{SIGSTKSZ} e \constd{MINSIGSTKSZ}, che possono essere utilizzate per
+allocare una quantità di spazio opportuna, in modo da evitare overflow. La
+prima delle due è la dimensione canonica per uno \textit{stack} di segnali e
+di norma è sufficiente per tutti gli usi normali.
+
+La seconda è lo spazio che occorre al sistema per essere in grado di lanciare
+il gestore e la dimensione di uno \textit{stack} alternativo deve essere
+sempre maggiore di questo valore. Quando si conosce esattamente quanto è lo
+spazio necessario al gestore gli si può aggiungere questo valore per allocare
+uno \textit{stack} di dimensione sufficiente.
+
+Come accennato, per poter essere usato, lo \textit{stack} per i segnali deve
+essere indicato al sistema attraverso la funzione \funcd{sigaltstack}; il suo
+prototipo è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigaltstack(const stack\_t *ss, stack\_t *oss)}
+\fdesc{Installa uno \textit{stack} alternativo per i gestori di segnali.}
+}
+
+{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}] uno degli indirizzi degli argomenti non è valido.
+ \item[\errcode{EINVAL}] \param{ss} non è nullo e \var{ss\_flags} contiene un
+ valore diverso da zero che non è \const{SS\_DISABLE}.
+ \item[\errcode{ENOMEM}] la dimensione specificata per il nuovo
+ \textit{stack} è minore di \const{MINSIGSTKSZ}.
+ \item[\errcode{EPERM}] si è cercato di cambiare lo \textit{stack}
+ alternativo mentre questo è attivo (cioè il processo è in esecuzione su di
+ esso).
+ \end{errlist}
+}
+\end{funcproto}
+
+La funzione prende come argomenti puntatori ad una struttura di tipo
+\var{stack\_t}, definita in fig.~\ref{fig:sig_stack_t}. I due valori
+\param{ss} e \param{oss}, se non nulli, indicano rispettivamente il nuovo
+\textit{stack} da installare e quello corrente (che viene restituito dalla
+funzione per un successivo ripristino).
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/stack_t.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{stack\_t}.}
+ \label{fig:sig_stack_t}
+\end{figure}
+
+Il campo \var{ss\_sp} di \struct{stack\_t} indica l'indirizzo base dello
+\textit{stack}, mentre \var{ss\_size} ne indica la dimensione; il campo
+\var{ss\_flags} invece indica lo stato dello \textit{stack}. Nell'indicare un
+nuovo \textit{stack} occorre inizializzare \var{ss\_sp} e \var{ss\_size}
+rispettivamente al puntatore e alla dimensione della memoria allocata, mentre
+\var{ss\_flags} deve essere nullo. Se invece si vuole disabilitare uno
+\textit{stack} occorre indicare \constd{SS\_DISABLE} come valore di
+\var{ss\_flags} e gli altri valori saranno ignorati.
+
+Se \param{oss} non è nullo verrà restituito dalla funzione indirizzo e
+dimensione dello \textit{stack} corrente nei relativi campi, mentre
+\var{ss\_flags} potrà assumere il valore \constd{SS\_ONSTACK} se il processo è
+in esecuzione sullo \textit{stack} alternativo (nel qual caso non è possibile
+cambiarlo) e \const{SS\_DISABLE} se questo non è abilitato.
+
+In genere si installa uno \textit{stack} alternativo per i segnali quando si
+teme di avere problemi di esaurimento dello \textit{stack} standard o di
+superamento di un limite (vedi sez.~\ref{sec:sys_resource_limit}) imposto con
+chiamate del tipo \code{setrlimit(RLIMIT\_STACK, \&rlim)}. In tal caso
+infatti si avrebbe un segnale di \signal{SIGSEGV}, che potrebbe essere gestito
+soltanto avendo abilitato uno \textit{stack} alternativo.
+
+Si tenga presente che le funzioni chiamate durante l'esecuzione sullo
+\textit{stack} alternativo continueranno ad usare quest'ultimo, che, al
+contrario di quanto avviene per lo \textit{stack} ordinario dei processi, non
+si accresce automaticamente (ed infatti eccederne le dimensioni può portare a
+conseguenze imprevedibili). Si ricordi infine che una chiamata ad una
+funzione della famiglia \func{exec} cancella ogni \textit{stack} alternativo.
+
+Abbiamo visto in fig.~\ref{fig:sig_sleep_incomplete} come si possa usare
+\func{longjmp} per uscire da un gestore rientrando direttamente nel corpo
+del programma, sappiamo però che nell'esecuzione di un gestore il segnale
+che l'ha invocato viene bloccato, e abbiamo detto che possiamo ulteriormente
+modificarlo con \func{sigprocmask}.
+
+Resta quindi il problema di cosa succede alla maschera dei segnali quando si
+esce da un gestore usando questa funzione. Il comportamento dipende
+dall'implementazione. In particolare la semantica usata da BSD prevede che sia
+ripristinata la maschera dei segnali precedente l'invocazione, come per un
+normale ritorno, mentre quella usata da System V no.
+
+Lo standard POSIX.1 non specifica questo comportamento per \func{setjmp} e
+\func{longjmp}, ed il comportamento della \acr{glibc} dipende da quale delle
+caratteristiche si sono abilitate con le macro viste in
+sez.~\ref{sec:intro_gcc_glibc_std}.
+
+Lo standard POSIX però prevede anche la presenza di altre due funzioni
+\funcd{sigsetjmp} e \funcd{siglongjmp}, che permettono di decidere in maniera
+esplicita quale dei due comportamenti il programma deve assumere; i loro
+prototipi sono:
+
+\begin{funcproto}{
+\fhead{setjmp.h}
+\fdecl{int sigsetjmp(sigjmp\_buf env, int savesigs)}
+\fdesc{Salva il contesto dello \textit{stack} e la maschera dei segnali.}
+\fdecl{void siglongjmp(sigjmp\_buf env, int val)}
+\fdesc{Ripristina il contesto dello \textit{stack} e la maschera dei segnali.}
+}
+
+{La funzioni sono identiche alle analoghe \func{setjmp} e \func{longjmp} di
+ sez.~\ref{sec:proc_longjmp} ed hanno gli stessi errori e valori di uscita.}
+\end{funcproto}
+
+Le due funzioni prendono come primo argomento la variabile su cui viene
+salvato il contesto dello \textit{stack} per permettere il salto non-locale;
+nel caso specifico essa è di tipo \typed{sigjmp\_buf}, e non \type{jmp\_buf}
+come per le analoghe di sez.~\ref{sec:proc_longjmp} in quanto in questo caso
+viene salvata anche la maschera dei segnali.
+
+Nel caso di \func{sigsetjmp}, se si specifica un valore di \param{savesigs}
+diverso da zero la maschera dei valori verrà salvata in \param{env} insieme al
+contesto dello \textit{stack} usato per il salto non locale. Se così si è
+fatto la maschera dei segnali verrà ripristinata in una successiva chiamata a
+\func{siglongjmp}. Quest'ultima, a parte l'uso di un valore di \param{env} di
+tipo \type{sigjmp\_buf}, è assolutamente identica a \func{longjmp}.
+
+
+% TODO: se e quando si troverà un argomento adeguato inserire altre funzioni
+% sparse attinenti ai segnali, al momento sono note solo:
+% * sigreturn (funzione interna, scarsamente interessante)
+% argomento a priorità IDLE (fare quando non resta niente altro da trattare)