-Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
-che abbia le stesse caratteristiche di \func{signal}, a definire attraverso
-\func{sigaction} una funzione equivalente \func{Signal}, il cui codice è
-riportato in fig.~\ref{fig:sig_Signal_code} (il codice completo si trova nel
-file \file{SigHand.c} nei sorgenti allegati). Si noti come, essendo la
-funzione estremamente semplice, essa è definita come
-\direct{inline};\footnote{la direttiva \direct{inline} viene usata per dire al
- compilatore di trattare la funzione cui essa fa riferimento in maniera
- speciale inserendo il codice direttamente nel testo del programma. Anche se
- i compilatori più moderni sono in grado di effettuare da soli queste
- manipolazioni (impostando le opportune ottimizzazioni) questa è una tecnica
- usata per migliorare le prestazioni per le funzioni piccole ed usate di
- frequente (in particolare nel kernel, dove in certi casi le ottimizzazioni
- dal compilatore, tarate per l'uso in user space, non sono sempre adatte). In
- tal caso infatti le istruzioni per creare un nuovo frame nello
- \itindex{stack} \textit{stack} per chiamare la funzione costituirebbero una
- parte rilevante del codice, appesantendo inutilmente il programma.
- Originariamente questo comportamento veniva ottenuto con delle macro, ma
- queste hanno tutta una serie di problemi di sintassi nel passaggio degli
- argomenti (si veda ad esempio \cite{PratC}) che in questo modo possono
- essere evitati.} per semplificare ulteriormente la definizione si è poi
-definito un apposito tipo \texttt{SigFunc}.
+Come primo esmpio si è allora provveduto, per mantenere un'interfaccia
+semplificata che abbia le stesse caratteristiche di \func{signal}, a definire
+attraverso \func{sigaction} una funzione equivalente, \func{Signal}, il cui
+codice è riportato in fig.~\ref{fig:sig_Signal_code} (il codice completo si
+trova nel file \file{SigHand.c} nei sorgenti allegati). Anche in questo caso,
+per semplificare la definizione si è poi definito un apposito tipo
+\texttt{SigHandler} per esprimere in modo più semplice la forma di un gestore
+di segnale.
+
+Si noti come, essendo la funzione estremamente semplice, essa è definita come
+\dirct{inline}. Questa direttiva viene usata per dire al compilatore di
+trattare la funzione cui essa fa riferimento in maniera speciale inserendo il
+codice direttamente nel testo del programma. Anche se i compilatori più
+moderni sono in grado di effettuare da soli queste manipolazioni (impostando
+le opportune ottimizzazioni) questa è una tecnica usata per migliorare le
+prestazioni per le funzioni piccole ed usate di frequente, in particolare nel
+kernel, dove in certi casi le ottimizzazioni dal compilatore, tarate per l'uso
+in \textit{user space}, non sono sempre adatte.
+
+In tal caso infatti le istruzioni per creare un nuovo frame nello
+\textit{stack} per chiamare la funzione costituirebbero una parte rilevante
+del codice, appesantendo inutilmente il programma. Originariamente questo
+comportamento veniva ottenuto con delle macro, ma queste hanno tutta una serie
+di problemi di sintassi nel passaggio degli argomenti (si veda ad esempio
+\cite{PratC}) che in questo modo possono essere evitati.
+
+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}