+ \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}[stepnumber=0]{}
+struct sigaction
+{
+ void (*sa_handler)(int);
+ void (*sa_sigaction)(int, siginfo_t *, void *);
+ sigset_t sa_mask;
+ int sa_flags;
+ void (*sa_restorer)(void);
+}
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{sigaction}.}
+ \label{fig:sig_sigaction}
+\end{figure}
+
+Il campo \var{sa\_mask} serve ad indicare l'insieme dei segnali che devono
+essere bloccati durante l'esecuzione del gestore, ad essi viene comunque
+sempre aggiunto il segnale che ne ha causato la chiamata, a meno che non si
+sia specificato con \var{sa\_flag} un comportamento diverso. Quando il
+gestore ritorna comunque la maschera dei segnali bloccati (vedi
+\secref{sec:sig_sigmask}) viene ripristinata al valore precedente
+l'invocazione.
+
+L'uso di questo campo permette ad esempio di risolvere il problema residuo
+dell'implementazione di \code{sleep} mostrata in
+\secref{fig:sig_sleep_incomplete}. In quel caso infatti se il segnale di
+allarme avesse interrotto un altro gestore questo non sarebbe stato
+eseguito correttamente; la cosa poteva essere prevenuta installando gli altri
+gestori usando \var{sa\_mask} per bloccare \const{SIGALRM} durante la
+loro esecuzione. Il valore di \var{sa\_flag} permette di specificare vari
+aspetti del comportamento di \func{sigaction}, e della reazione del processo
+ai vari segnali; i valori possibili ed il relativo significato sono riportati
+in \tabref{tab:sig_sa_flag}.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{SA\_NOCLDSTOP}& Se il segnale è \const{SIGCHLD} allora non deve
+ essere notificato quando il processo figlio viene
+ fermato da uno dei segnali \const{SIGSTOP},
+ \const{SIGTSTP}, \const{SIGTTIN} o
+ \const{SIGTTOU}.\\
+ \const{SA\_ONESHOT} & Ristabilisce l'azione per il segnale al valore
+ predefinito una volta che il gestore è stato
+ lanciato, riproduce cioè il comportamento della
+ semantica inaffidabile.\\
+ \const{SA\_RESETHAND}& Sinonimo di \const{SA\_ONESHOT}. \\
+ \const{SA\_RESTART} & Riavvia automaticamente le \textit{slow system
+ call} quando vengono interrotte dal suddetto
+ segnale; riproduce cioè il comportamento standard
+ di BSD.\\
+ \const{SA\_NOMASK} & Evita che il segnale corrente sia bloccato durante
+ l'esecuzione del gestore.\\
+ \const{SA\_NODEFER} & Sinonimo di \const{SA\_NOMASK}.\\
+ \const{SA\_SIGINFO} & Deve essere specificato quando si vuole usare un
+ gestore in forma estesa usando
+ \var{sa\_sigaction} al posto di \var{sa\_handler}.\\
+ \const{SA\_ONSTACK} & Stabilisce l'uso di uno stack alternativo per
+ l'esecuzione del gestore (vedi
+ \secref{sec:sig_specific_features}).\\
+ \hline
+ \end{tabular}
+ \caption{Valori del campo \var{sa\_flag} della struttura \struct{sigaction}.}
+ \label{tab:sig_sa_flag}
+\end{table}
+
+Come si può notare in \figref{fig:sig_sigaction} \func{sigaction}
+permette\footnote{La possibilità è prevista dallo standard POSIX.1b, ed è
+ stata aggiunta nei kernel della serie 2.1.x con l'introduzione dei segnali
+ real-time (vedi \secref{sec:sig_real_time}). In precedenza era possibile
+ ottenere alcune informazioni addizionali usando \var{sa\_handler} con un
+ secondo parametro addizionale di tipo \var{sigcontext}, che adesso è
+ deprecato.} di utilizzare due forme diverse di gestore, da specificare, a
+seconda dell'uso o meno del flag \const{SA\_SIGINFO}, rispettivamente
+attraverso i campi \var{sa\_sigaction} o \var{sa\_handler},\footnote{i due
+ tipi devono essere usati in maniera alternativa, in certe implementazioni
+ questi campi vengono addirittura definiti come \ctyp{union}.} Quest'ultima
+è quella classica usata anche con \func{signal}, mentre la prima permette di
+usare un gestore più complesso, in grado di ricevere informazioni più
+dettagliate dal sistema, attraverso la struttura \struct{siginfo\_t},
+riportata in \figref{fig:sig_siginfo_t}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[stepnumber=0]{}
+siginfo_t {
+ int si_signo; /* Signal number */
+ int si_errno; /* An errno value */
+ int si_code; /* Signal code */
+ pid_t si_pid; /* Sending process ID */
+ uid_t si_uid; /* Real user ID of sending process */
+ int si_status; /* Exit value or signal */
+ clock_t si_utime; /* User time consumed */
+ clock_t si_stime; /* System time consumed */
+ sigval_t si_value; /* Signal value */
+ int si_int; /* POSIX.1b signal */
+ void * si_ptr; /* POSIX.1b signal */
+ void * si_addr; /* Memory location which caused fault */
+ int si_band; /* Band event */
+ int si_fd; /* File descriptor */
+}