-notifica di una scadenza, il comportamento del sistema è indefinito.
-
-
-
-\subsection{Le interfacce per la notifica attraverso i file descriptor}
-\label{sec:sig_signalfd_eventfd}
-
-I segnali sono uno dei meccanismi classici, presenti da sempre nei sistemi
-unix-like, per effettuare notifiche ai processi, la loro interfaccia di
-programmazione però, che comporta l'esecuzione di una funzione di gestione in
-maniera asincrona e totalmente scorrelata dall'ordinario flusso di esecuzione
-del processo, si è dimostrata quasi subito assai problematica.
-
-Oltre ai limiti relativi ai limiti sul cosa si può fare nel gestore di segnali
-(quelli illustrati in sez.~\ref{sec:sig_signal_handler}), c'è un problema più
-generale consistente nel fatto che questa modalità di funzionamento cozza con
-altre interfacce di programmazione previste dal sistema in cui invece si opera
-in maniera \textsl{sincrona}, e che porta ai problemi relativi alla
-interruzione delle system call bloccanti.
-
-In questo caso infatti si aspetta che il processo gestisca gli eventi (che
-causano l'uscita dalla system call bloccante) generando le opportune risposte,
-mentre con l'arrivo di un segnale ci si trova alla possibilità di avere
-interruzioni asincrone in cui possono essere eseguite operazioni fuori dal
-resto dal flusso ordinario del programma e quindi la necessità gestire le
-interruzioni ed evitare possibili \itindex{race~condition} \textit{race
- conditions}.\footnote{in sostanza se non fosse per i segnali non ci sarebbe
- da doversi preoccupare, fintanto che si effettuano operazioni all'interno
- dello stesso, della non atomicità delle stesse (si ricordi quanto detto in
- sez.~\ref{sec:proc_atom_oper}).}
-
-In particolare, come vedremo in sez.~\ref{sec:file_select}, i segnali hanno
-una pessima interazione con le funzioni di gestione dell'I/O multiplexing, che
-costituiscono un meccanismo efficiente per gestire in maniera sincrona
-l'accesso a più file o socket in cui il processo si blocca fintanto che non ci
-sono dati da leggere o scrivere su uno qualunque fra i file descriptor ad essi
-associati.\footnote{per la trattazione dettagliata del significato e dei
- vantaggi dell'I/O multiplexing si rimanda a
- sez.~\ref{sec:file_multiplexing}, per la trattazione dei problemi
- dell'interazione coi segnali si veda quanto illustrato in
- sez.~\ref{sec:file_select} riguardo la necessità di \func{pselect}.}
-
-Abbiamo visto però in sez.~\ref{sec:sig_real_time} che insieme ai segnali
-\textit{real-time} sono state introdotte delle interfacce di gestione sincrona
-dei segnali con la funzione \func{sigwait} e le sue affini. Queste funzioni
-consentono di gestire i segnali bloccando un processo fino alla avvenuta
-ricezione e disabilitando l'esecuzione asincrona di un gestore. Questo
-consente di risolvere i problemi di atomicità nella gestione degli eventi
-associati ai segnali, avendo tutto il controllo nel flusso principale del
-programma, ottenendo così una gestione simile a quella dell'I/O multiplexing,
-però non risolve i problemi dell'interazioni con quest'ultimo perché o si
-aspetta la ricezione di un segnale o si aspetta che un file descriptor sia
-accessibile e nessuna delle relative funzioni consente di fare
-contemporaneamente entrambe le cose.
-
-Per risolvere questo problema nello sviluppo del kernel si è pensato di
-introdurre un meccanismo alternativo per la notifica dei segnali (ed anche di
-altri eventi generici) che, ispirandosi di nuovo alla filosofia di Unix per
-cui tutto è un file, consentisse di eseguirne la notifica con l'uso di file
-descriptor.\footnote{ovviamente si tratta di una funzionalità specifica di
- Linux, non presente in altri sistemi unix-like, e non prevista da nessuno
- standard.} In sostanza come per \func{sigwait} si può disabilitare
-l'esecuzione di un gestore di segnali, e rilevare l'avvenuta emissione di un
-segnale leggendone la notifica da un file descriptor speciale; ma essendo
-questo comunque un file descriptor potrà essere tenuto sotto osservazione con
-le funzioni dell'I/O multiplexing come quelli associati a file o socket, per
-cui alla fine si potrà attendere in contemporanea sia il segnale che la
-disponibilità di accesso a questi ultimi.
-
-
-
-
-% TODO trattare qui eventfd signalfd e timerfd introdotte con il 2.6.22
-% timerfd è stata tolta nel 2.6.23 e rifatta per bene nel 2.6.25
-% vedi: http://lwn.net/Articles/233462/
-% http://lwn.net/Articles/245533/
-% http://lwn.net/Articles/267331/
+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} .
+
+% TODO manca clock_nanosleep, referenziata in sez.~\ref{sec:sig_gen_beha}
+
+\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 \itindex{stack} \textit{stack} alternativo per i segnali; è cioè
+possibile fare usare al sistema un altro \itindex{stack} \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,
+\const{SIGSTKSZ} e \const{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 \itindex{stack}
+\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 \itindex{stack} \textit{stack} di dimensione sufficiente.
+
+Come accennato, per poter essere usato, lo \itindex{stack} \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
+\itindex{stack} \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
+\itindex{stack} \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 \const{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 \itindex{stack} \textit{stack} corrente nei relativi campi,
+mentre \var{ss\_flags} potrà assumere il valore \const{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 \itindex{stack} \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 \itindex{stack} \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 \itindex{stack} \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 delle \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 \itindex{stack} \textit{stack} per permettere il
+\index{salto~non-locale} salto non-locale; nel caso specifico essa è di tipo
+\type{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 \itindex{stack} \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}.