+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{14cm}
+ \func{ffs}, \func{htonl}, \func{htons}, \func{longjmp}, \func{memccpy},
+ \func{memchr}, \func{memcmp}, \func{memcpy}, \func{memmove}, \func{memset},
+ \func{siglongjmp}, \func{stpcpy}, \func{stpncpy}, \func{strcat},
+ \func{strchr}, \func{strcmp}, \func{strcpy}, \func{strcspn},
+ \func{strlen}, \func{strncat}, \func{strncmp}, \func{strncpy},
+ \func{strnlen}, \func{strpbrk}, \func{strrchr}, \func{strspn},
+ \func{strstr}, \func{strtok\_r}, \func{wcpcpy}, \func{wcpncpy},
+ \func{wcscat}, \func{wcschr}, \func{wcscmp}, \func{wcscpy},
+ \func{wcscspn}, \func{wcslen}, \func{wcsncat}, \func{wcsncmp},
+ \func{wcsncpy}, \func{wcsnlen}, \func{wcspbrk}, \func{wcsrchr},
+ \func{wcsspn}, \func{wcsstr}, \func{wcstok}, \func{wmemchr},
+ \func{wmemcmp}, \func{wmemcpy}, \func{wmemmove}, \func{wmemset}.
+ \end{minipage}
+ \normalsize
+ \caption{Ulteriori funzioni sicure secondo lo standard POSIX.1-2016.}
+ \label{fig:sig_safe_functions_posix_2016}
+\end{figure}
+
+Rispetto a questi elenchi occorre precisare che prima della versione 2.24
+delle \acr{glibc} l'implementazione delle funzioni \func{execl} ed
+\func{execle} non era sicura, e che tuttora non lo è quella di
+\func{aio\_suspend}. Inoltre è da evitare \func{fork}, che potrebbe essere
+rimossa in future revisioni dello standard, e che già POSIX-1.2003 indicava
+come tale se usata in concorrenza con \func{pthread\_atfork}.
+
+\index{funzioni!\textit{signal safe}|)}
+
+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 i segnali \textit{real-time} vengono numerati a partire da 32, fino
+ad un valore massimo di 64, per un totale di 33 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} fornito
+quando si usano le \acr{glibc} 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 numerico assoluto, dato che si potrebbe correre il
+rischio di utilizzare un segnale già in uso alle librerie; il numero del
+segnale deve invece essere sempre specificato in forma relativa a
+\const{SIGRTMIN}, con qualcosa come \code{SIGRTMIN + n}, avendo sempre cura di
+controllare di non aver indicato un valore maggiore di \const{SIGRTMAX}.
+
+I segnali \textit{real-time} 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 è sempre quella di terminare il
+programma. I segnali ordinari invece hanno tutti la stessa priorità, che è
+più alta di quella di qualunque segnale \textit{real-time}.\footnote{questa è
+ però una caratteristica di Linux, presente comunque anche nella gran parte
+ degli altri kernel \textit{unix-like}, lo standard infatti non definisce
+ niente al riguardo.}
+
+Si tenga presente che questi nuovi segnali non sono associati a nessun evento
+specifico, a meno di non avere richiesto l'utilizzo di uno di essi 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 nell'uso ordinario devono essere
+inviati esplicitamente.
+
+Inoltre, per poter usufruire della loro 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 di \struct{siginfo\_t} utilizzati dai segnali
+\textit{real-time} sono \var{si\_pid} e \var{si\_uid} in cui vengono riportati
+rispettivamente il \ids{PID} e l'\ids{UID} effettivo del processo che ha
+inviato il segnale, e lo specifico campo \var{si\_value}. Questo campo viene
+indicato in fig.~\ref{fig:sig_siginfo_t} come di tipo \type{sigval\_t}; se ne
+è riportata la definizione in fig.~\ref{fig:sig_sigval}.
+
+\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}
+
+
+Si tratta quindi di una unione \struct{sigval} con due possibili campi
+alternativi in cui può essere memorizzato o un valore numerico, se usata con
+\var{sival\_int}, o un puntatore, se usata con \var{sival\_ptr}. L'unione
+viene usata dai segnali \textit{real-time}, ma anche da vari altri meccanismi
+di notifica, per inviare eventuali informazioni aggiuntive al gestore del
+segnale in \var{si\_value}. Ad esempio un campo di tipo \type{sigval\_t} è
+presente anche nella struttura \struct{sigevent} (definita in
+fig.~\ref{fig:struct_sigevent}) che viene usata da vari meccanismi di notifica
+come quelli per i timer POSIX (che vedremo in sez.~\ref{sec:sig_timer_adv}),
+quello dell'I/O asincrono (che vedremo in sez.~\ref{sec:file_asyncronous_io})
+o dalle code di messaggi POSIX (che vedremo in sez.~\ref{sec:ipc_posix_mq}).
+
+A causa di questa loro caratteristica, la funzione \func{kill}, pure essendo
+utilizzabile, non è adatta ad inviare segnali \textit{real-time}, perché non è
+in grado di impostare alcun valore per il campo \var{si\_value}. Per questo
+motivo lo standard POSIX 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 ed un valore positivo in caso di
+ errore con valore secondo la lista seguente:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] \param{set} contiene un numero di segnale non valido
+ \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.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/rtsigvalsend.c}
+ \end{minipage}
+ \normalsize
+ \caption{Corpo principale di un programma di invio di segnali
+ \textit{real-time}.}
+ \label{fig:sig_rtsival_main}
+\end{figure}
+
+Come esempio elementare dell'uso dei segnali \textit{real-time}, e della
+possibilità di inviare informazioni al gestore degli stessi con
+\func{sigqueue}, si è riportato in fig.~\ref{fig:sig_rtsival_main} il corpo
+principale di un programma elementare che legge dal terminale un valore
+numerico, ed utilizza un segnale \textit{real-time} per inviarlo al gestore
+dello stesso. Nel codice sono stati trascurati i controlli dei valori di
+ritorno delle varie funzioni per mantenere la brevità dell'esempio.
+
+Dopo aver definito (\texttt{\small 5}) una variabile \var{value} di tipo
+\type{sigval\_t} per poter inviare i dati, e dopo aver opportunamente scelto
+(\texttt{\small 6}) per \var{signo} un segnale \textit{real-time}, la parte
+iniziale del programma (\texttt{\small 8--11}) installa il relativo gestore
+(la cui definizione è riportata in fig.~\ref{fig:sig_rtsival_handl}). Dopo di
+che il programma si pone in un ciclo infinito (\texttt{\small 14--27}) in cui
+prima (\texttt{\small 15--20}) legge in buffer dallo \textit{standard input}
+una stringa immessa dall'utente, terminandola opportunamente (\texttt{\small
+ 20}), e poi tenta di convertire la stessa (\texttt{\small 21}) in un numero
+con \func{strtol}, assegnando il risultato a \texttt{value.sival\_int}, se la
+conversione ha successo e \texttt{value.sival\_int} è positivo) invia a se
+stesso (\texttt{\small 23}) il segnale \textit{real-time}, altrimenti stampa
+un avviso (\texttt{\small 24}).
+
+Alla ricezione del segnale il gestore si limita a stampare alcune delle
+informazioni ricevute nella struttura \struct{sigval\_t}, ed in particolare
+(\texttt{\small 5}) stampa tramite il valore del campo \var{si\_value} il
+numero che gli è stato inviato da \func{sigqueue}.