+La funzione \func{Signal} appena illustrata continua però ad utilizzare la
+forma tradizionale del gestore di segnali, mentre abbiamo visto come
+\func{sigaction} preveda la possibilità di indicare, attivando il flag
+\const{SA\_SIGINFO}, un gestore nella forma avanzata \param{sa\_sigaction}, in
+grado di ricevere molte più informazioni, che prevede l'utilizzo di tre
+argomenti. Di nuovo facciamo un esempio di come usare \func{sigaction} in
+questo caso, partendo col definire un apposito tipo, \texttt{SigAction}, per
+semplificare l'indicazione del nuovo tipo di gestore:
+\includecodesnip{listati/SigAction.c}
+
+Un gestore di segnali definito nella forma \val{sa\_sigaction} infatti, oltre
+al numero di segnale ricevuto come primo argomento, otterrà dal kernel un
+puntatore ad una struttura \struct{siginfo\_t} con le relative informazioni
+attienti l'origine del segnale nel secondo argomento, ed infine un puntatore a
+delle informazioni di contesto ad uso delle librerie del C nel terzo
+argomento, che non vengono mai utilizzate nel gestore, attenendo al
+funzionamento a basso livello della gestione dei segnali.\footnote{il kernel
+ tutte le volte che c'è un segnale pendente gestisce l'esecuzione del
+ relativo gestore caricando nello stack i dati del contesto di esecuzione del
+ processo e facendo sì che al ritorno in \textit{user-space} sia eseguito il
+ gestore, una volta che questo ritorna il controllo viene passato a dello
+ specifico codice in \textit{user-space}, detto \itindex{signal~trampoline}
+ \textit{signal trampoline}, che con la funzione di sistema \funcm{sigreturn}
+ usa le informazioni di contesto disponibili in questo argomento per far
+ riprendere l'esecuzione del processo al punto in cui si era stata interrotta
+ dal segnale; tutto ciò è gestito dal kernel e dalle librerie del C e non
+ interessa la programmazione ordinaria.}
+
+Si è riportato in fig.~\ref{fig:sig_Action_code} un equivalente della
+precedente \func{Signal} che però installa un gestore di segnali di tipo
+\param{sa\_sigaction}. Si noti come la funzione, una volta definito come sopra
+il tipo \texttt{SigAction} per il gestore di segnali, sia praticamente
+identica all'altra.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/Action.c}
+ \end{minipage}
+ \normalsize
+ \caption{La funzione \func{Action}, analoga alla precedente \func{Signal}
+ per l'uso dei gestori di segnali avanzati con \func{sigaction}.}
+ \label{fig:sig_Action_code}
+\end{figure}
+
+Quello che cambia in questo caso è occorre indicare (\texttt{\small 4}) nel
+campo \var{sa\_flags} della struttura \struct{sigaction} il valore
+\const{SA\_SIGINFO}, perché poi si passerà (\texttt{\small 5}) l'indirizzo il
+del gestore nel campo \var{sa\_sigaction} invece che in \var{sa\_handler} come
+nel caso precedente.
+
+Inoltre in questo caso, ritornando la funzione l'indirizzo del gestore che è
+nella nuova forma, non si può terminare in caso di errore riportanto il valore
+\const{SIG\_ERR} (che è di tipo \type{sighandler\_t} e fa riferimento ad un
+gestore ordinario) come in precedenza. Per questo motivo si è scelto di
+ritornare come indicazione di errore il valore \val{NULL}, ma in questo caso
+si deve tenere presente che questo valore non è più distinto da quello che si
+utilizza per indicare la eventuale reimpostazione del gestore di default (come
+era \const{SIG\_ERR} rispetto a \const{SIG\_DFL}).
+
+Per questo motivo questa funzione viene illustrata solo a scopo di primo
+esempio, vedremo più avanti, in sez.~\ref{sec:sig_real_time}, nel contesto
+dell'uso dei segnali \textit{real-time} per i quali è nata questa nuova
+interfaccia, un esempio più completo dell'uso di \func{sigaction} con un
+gestore in questa nuova forma, e di come utilizzare le informazioni ottenute
+nella struttura \struct{siginfo\_t}.