+\section{La gestione dei segnali}
+\label{sec:sig_management}
+
+I segnali sono il primo e più classico esempio di eventi asincroni, cioè di
+eventi che possono accadere in un qualunque momento durante l'esecuzione di un
+programma. Dato che la loro gestione non è sotto il controllo del programma
+essa non può essere effettuata all'interno del normale flusso di esecuzione.
+
+In questa sezione vedremo come si effettua gestione dei segnali, a partire dal
+comportamento del sistema, passando per le varie funzioni relative ai segnali,
+affrontando inoltre le varie promblematiche di programmazione che si devono
+tenere presenti quando si ha a che fare con essi.
+
+
+\subsection{Il comportamento generale del sistema.}
+\label{sec:sig_gen_beha}
+
+Abbiamo già trattato in \secref{sec:sig_intro} le modalità con cui il sistema
+gestisce l'interazione fra segnali e processi, ci resta da esaminare però il
+comportamento delle system call; in particolare due di esse, \func{fork} ed
+\func{exec}, dovranno essere prese esplicitamente in considerazione, data la
+loro stretta relazione con la creazione di nuovi processi.
+
+Come accennato in \secref{sec:proc_fork} quando viene creato un nuovo processo
+con \func{fork} esso eredita dal padre sia le azioni che sono state settate
+per i singoli segnali, che la maschera dei segnali bloccati (tratteremo
+quest'ultimo argomento in \ref{sec:sig_sigpending}). Invece tutti i segnali
+pendenti e gli allarmi vengono cancellati; essi infatti devono essere
+recapitati solo al padre, al figlio dovranno arrivare solo i segnali dovuti
+alle sue azioni.
+
+Quando si mette in esecuzione un nuovo programma con \func{exec} (si ricordi
+quanto detto in \secref{sec:prog_exec}) tutti i segnali per i quali è stato
+installato un manipolatore vengono resettati a \macro{SIG\_DFL}. Non ha più
+senso infatti fare riferimento a funzioni definite nel programma originario,
+che non sono nemmeno presenti nello spazio di indirizzi del nuovo programma.
+
+Si noti che questo vale solo per le azioni per le quali è stato installato un
+manipolatore; viene mantenuto invece ogni eventuale settaggio dell'azione a
+\macro{SIG\_IGN}. Questo permette ad esempio alla shell di settare ad
+\macro{SIG\_IGN} le risposte per \macro{SIGINT} e \macro{SIGQUIT} per i
+programmi eseguiti in background, che altrimenti sarebbero interrotti da una
+successiva pressione di \texttt{C-c} o \texttt{C-y}.
+
+Per quanto riguarda tutte le altre system call esse vengono tradizionalmente
+classificate, proprio in base al loro comportamento nei confronti dei segnali,
+in lente (\textit{slow}) e veloci (\textit{fast}). La gran parte appartiene a
+quest'ultima categoria che non è influenzata dall'arrivo di un segnale. In tal
+caso un eventuale manipolatore viene sempre eseguito dopo che la system call è
+stata completata. Esse sono dette \textit{fast} proprio in quanto attendere la
+loro esecuzione per eseguire un manipolatore non comporta nessun
+inconveniente.
+
+Esistono però dei casi (ad esempio le funzioni di I/O che si bloccano in
+attesa di dati in ingresso) in cui tutto questo non è possibile proprio perché
+renderebbe impossibile una risposta pronta al segnale (per questo sono
+chiamate \textit{slow}), pertanto un eventuale manipolatore sarà eseguito
+prima che la system call sia ritornata.
+
+In quest'ultimo caso si pone il problema di cosa fare una volta che il
+manipolatori ritorni. La scelta