qualunque momento, e le operazioni di un eventuale \textit{signal handler}
sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
il solo accesso o l'assegnazione di una variabile possono non essere più
-operazioni atomiche (torneremo su questi aspetti in \secref{sec:sign_xxx}).
+operazioni atomiche (torneremo su questi aspetti in
+\secref{sec:sign_control}).
In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
il cui accesso è assicurato essere atomico. In pratica comunque si può
\label{fig:sig_timespec_def}
\end{figure}
-Ma questa, a parte il non gestire il caso in cui si è avuta una precedente
-chiamata a \func{alarm}, presenta una pericolosa race condition. Infatti se il
-processo viene interrotto fra la chiamata di \func{alarm} e \func{pause} può
-capitare (nel caso il sistema sia molto carico) che quest'ultima possa essere
-eseguita dopo l'arrivo di \macro{SIGALRM}. In questo caso ci si troverebbe di
-fronte ad un deadlock, in cui \func{pause} non verrebbe mai interrotta (se non
-in caso di un altro segnale).
+Ma questa funzione, a parte il non gestire il caso in cui si è avuta una
+precedente chiamata a \func{alarm}, presenta una pericolosa race condition.
+Infatti se il processo viene interrotto fra la chiamata di \func{alarm} e
+\func{pause} può capitare (nel caso il sistema sia molto carico) che
+quest'ultima possa essere eseguita dopo l'arrivo di \macro{SIGALRM}. In questo
+caso ci si troverebbe di fronte ad un deadlock, in cui \func{pause} non
+verrebbe mai interrotta (se non in caso di un altro segnale).
+
+Come abbiamo accennato in \secref{sec:proc_atom_oper} quando si ha a che fare
+con i segnali
+
+
\subsection{Le funzioni \func{sigprocmask} e \func{sigpending}}