+ \end{lstlisting}
+ \normalsize
+ \caption{Una implementazione ancora malfunzionante di \func{sleep}.}
+ \label{fig:sig_sleep_incomplete}
+\end{figure}
+
+In questo caso il gestore (\texttt{\small 18-26}) non ritorna come in
+\figref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 24}) per
+rientrare nel corpo principale del programma; dato che in questo caso il
+valore di uscita di \func{setjmp} è 1, grazie alla condizione in
+(\texttt{\small 9-12}) si evita comunque che \func{pause} sia chiamata a
+vuoto.
+
+Ma anche questa implementazione comporta dei problemi; in questo caso infatti
+non viene gestita correttamente l'interazione con gli altri segnali; se
+infatti il segnale di allarme interrompe un altro gestore, in questo caso
+l'esecuzione non riprenderà nel gestore in questione, ma nel ciclo
+principale, interrompendone inopportunamente l'esecuzione. Lo stesso tipo di
+problemi si presenterebbero se si volesse usare \func{alarm} per stabilire un
+timeout su una qualunque system call bloccante.
+
+Un secondo esempio è quello in cui si usa il segnale per notificare una
+qualche forma di evento; in genere quello che si fa in questo caso è impostare
+nel gestore un opportuno flag da controllare nel corpo principale del
+programma (con un codice del tipo di quello riportato in
+\figref{fig:sig_event_wrong}).
+
+\begin{figure}[!htb]
+ \footnotesize
+ \begin{lstlisting}{}
+sig_atomic_t flag;
+int main()
+{
+ flag = 0;
+ ...
+ if (flag) { /* test if signal occurred */
+ flag = 0; /* reset flag */
+ do_response(); /* do things */
+ } else {
+ do_other(); /* do other things */
+ }
+ ...
+}
+void alarm_hand(int sig)
+{
+ /* set the flag
+ flag = 1;
+ return;
+}
+ \end{lstlisting}
+ \normalsize
+ \caption{Un esempio non funzionante del codice per il controllo di un
+ evento generato da un segnale.}
+ \label{fig:sig_event_wrong}
+\end{figure}
+
+La logica è quella di far impostare al gestore (\texttt{\small 14-19}) una
+variabile globale preventivamente inizializzata nel programma principale, il
+quale potrà determinare, osservandone il contenuto, l'occorrenza o meno del
+segnale, e prendere le relative azioni conseguenti (\texttt{\small 6-11}).
+
+Questo è il tipico esempio di caso, già citato in \secref{sec:proc_race_cond},
+in cui si genera una race condition\index{race condition}; se infatti il
+segnale arriva immediatamente dopo l'esecuzione del controllo (\texttt{\small
+ 6}) ma prima della cancellazione del flag (\texttt{\small 7}), la sua
+occorrenza sarà perduta.
+
+Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono
+funzioni più sofisticate di quelle illustrate finora, che hanno origine dalla
+interfaccia semplice, ma poco sofisticata, dei primi sistemi Unix, in modo da
+consentire la gestione di tutti i possibili aspetti con cui un processo deve
+reagire alla ricezione di un segnale.
+
+
+
+\subsection{Gli \textsl{insiemi di segnali} o \textit{signal set}}
+\label{sec:sig_sigset}
+
+Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali
+dei primi Unix, nate con la semantica inaffidabile, hanno dei limiti non
+superabili; in particolare non è prevista nessuna funzione che permetta di
+gestire gestire il blocco dei segnali o di verificare lo stato dei segnali
+pendenti.
+
+Per questo motivo lo standard POSIX.1, insieme alla nuova semantica dei
+segnali ha introdotto una interfaccia di gestione completamente nuova, che
+permette di ottenete un controllo molto più dettagliato. In particolare lo
+standard ha introdotto un nuovo tipo di dato \type{sigset\_t}, che permette di
+rappresentare un \textsl{insieme di segnali} (un \textit{signal set}, come
+viene usualmente chiamato), che è il tipo di dato che viene usato per gestire
+il blocco dei segnali.
+
+In genere un \textsl{insieme di segnali} è rappresentato da un intero di
+dimensione opportuna, di solito si pari al numero di bit dell'architettura
+della macchina\footnote{nel caso dei PC questo comporta un massimo di 32
+ segnali distinti, dato che in Linux questi sono sufficienti non c'è
+ necessità di nessuna struttura più complicata.}, ciascun bit del quale è
+associato ad uno specifico segnale; in questo modo è di solito possibile
+implementare le operazioni direttamente con istruzioni elementari del
+processore; lo standard POSIX.1 definisce cinque funzioni per la manipolazione
+degli insiemi di segnali: \funcd{sigemptyset}, \funcd{sigfillset},
+\funcd{sigaddset}, \funcd{sigdelset} e \funcd{sigismember}, i cui prototipi
+sono:
+\begin{functions}
+ \headdecl{signal.h}
+
+ \funcdecl{int sigemptyset(sigset\_t *set)} Inizializza un insieme di segnali
+ vuoto (in cui non c'è nessun segnale).
+
+ \funcdecl{int sigfillset(sigset\_t *set)} Inizializza un insieme di segnali
+ pieno (in cui ci sono tutti i segnali).
+
+ \funcdecl{int sigaddset(sigset\_t *set, int signum)} Aggiunge il segnale
+ \param{signum} all'insieme di segnali \param{set}.
+
+ \funcdecl{int sigdelset(sigset\_t *set, int signum)} Toglie il segnale
+ \param{signum} dall'insieme di segnali \param{set}.
+
+ \funcdecl{int sigismember(const sigset\_t *set, int signum)} Controlla se il
+ segnale \param{signum} è nell'insieme di segnali \param{set}.
+
+ \bodydesc{Le prime quattro funzioni ritornano 0 in caso di successo, mentre
+ \func{sigismember} ritorna 1 se \param{signum} è in \param{set} e 0
+ altrimenti. In caso di errore tutte ritornano -1, con \var{errno}
+ impostata a \errval{EINVAL} (il solo errore possibile è che \param{signum}
+ non sia un segnale valido).}
+\end{functions}
+
+Dato che in generale non si può fare conto sulle caratteristiche di una
+implementazione (non è detto che si disponga di un numero di bit sufficienti
+per mettere tutti i segnali in un intero, o in \type{sigset\_t} possono essere
+immagazzinate ulteriori informazioni) tutte le operazioni devono essere
+comunque eseguite attraverso queste funzioni.
+
+In genere si usa un insieme di segnali per specificare quali segnali si vuole
+bloccare, o per riottenere dalle varie funzioni di gestione la maschera dei
+segnali attivi (vedi \secref{sec:sig_sigmask}). Essi possono essere definiti
+in due diverse maniere, aggiungendo i segnali voluti ad un insieme vuoto
+ottenuto con \func{sigemptyset} o togliendo quelli che non servono da un
+insieme completo ottenuto con \func{sigfillset}. Infine \func{sigismember}
+permette di verificare la presenza di uno specifico segnale in un
+insieme.
+
+
+\subsection{La funzione \func{sigaction}}
+\label{sec:sig_sigaction}
+
+Abbiamo già accennato in \secref{sec:sig_signal} i problemi di compatibilità
+relativi all'uso di \func{signal}. Per ovviare a tutto questo lo standard
+POSIX.1 ha ridefinito completamente l'interfaccia per la gestione dei segnali,
+rendendola molto più flessibile e robusta, anche se leggermente più complessa.
+
+La funzione principale dell'interfaccia POSIX.1 per i segnali è
+\funcd{sigaction}. Essa ha sostanzialemente lo stesso uso di \func{signal},
+permette cioè di specificare le modalità con cui un segnale può essere gestito
+da un processo. Il suo prototipo è:
+\begin{prototype}{signal.h}{int sigaction(int signum, const struct sigaction
+ *act, struct sigaction *oldact)}
+
+ Installa una nuova azione per il segnale \param{signum}.
+
+ \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
+ errore, nel qual caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] Si è specificato un numero di segnale invalido o si è
+ cercato di installare il gestore per \const{SIGKILL} o
+ \const{SIGSTOP}.
+ \item[\errcode{EFAULT}] Si sono specificati indirizzi non validi.
+ \end{errlist}}
+\end{prototype}
+
+La funzione serve ad installare una nuova \textsl{azione} per il segnale
+\param{signum}; si parla di \textsl{azione} e non di \textsl{gestore}
+come nel caso di \func{signal}, in quanto la funzione consente di specificare
+le varie caratteristiche della risposta al segnale, non solo la funzione che
+verrà eseguita alla sua occorrenza. Per questo lo standard raccomanda di
+usare sempre questa funzione al posto di \func{signal} (che in genere viene
+definita tramite essa), in quanto permette un controllo completo su tutti gli
+aspetti della gestione di un segnale, sia pure al prezzo di una maggiore
+complessità d'uso.
+
+Se il puntatore \param{act} non è nullo, la funzione installa la nuova azione
+da esso specificata, se \param{oldact} non è nullo il valore dell'azione
+corrente viene restituito indietro. Questo permette (specificando \param{act}
+nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
+che non consente di ottenere l'azione corrente senza installarne una nuova.
+
+Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
+tramite la quale si specificano tutte le caratteristiche dell'azione associata
+ad un segnale. Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
+definita secondo quanto riportato in \figref{fig:sig_sigaction}. Il campo
+\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
+più usato.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+struct sigaction
+{
+ void (*sa_handler)(int);
+ void (*sa_sigaction)(int, siginfo_t *, void *);
+ sigset_t sa_mask;
+ int sa_flags;
+ void (*sa_restorer)(void);
+}