Risistemazioni varie, lavori in corso

diff --git a/signal.tex b/signal.tex
index 1f0649db98fba4f9895f8a0af72ca997c2b57234..966e32a1aa0759a2d1d6b15210171c3f2680d5e7 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -84,8 +84,7 @@ attivo.
 In questo caso è possibile una situazione in cui i segnali possono essere
 perduti. Si consideri il seguente segmento di codice, in cui la prima
 operazione del manipolatore è quella di reinstallare se stesso: 
 In questo caso è possibile una situazione in cui i segnali possono essere
 perduti. Si consideri il seguente segmento di codice, in cui la prima
 operazione del manipolatore è quella di reinstallare se stesso: 

-s
-e un secondo segnale arriva prima che il manipolatore invocato dal primo
+se un secondo segnale arriva prima che il manipolatore invocato dal primo

 abbia eseguito la reinstallazione di se stesso il segnale può essere perso o
 causare il comportamento originale assegnato al segnale (in genere la
 terminazione del processo).
 abbia eseguito la reinstallazione di se stesso il segnale può essere perso o
 causare il comportamento originale assegnato al segnale (in genere la
 terminazione del processo).


@@ -1501,7 +1500,7 @@ fino a trattare le caratteristiche generali della gestione dei medesimi nella
 casistica ordinaria.
 
 
 casistica ordinaria.
 
 

-\subsection{Un esempio di problema}
+\subsection{Alcune problematiche aperte}

 \label{sec:sig_example}
 
 Come accennato in \secref{sec:sig_pause_sleep} è possibile implementare
 \label{sec:sig_example}
 
 Come accennato in \secref{sec:sig_pause_sleep} è possibile implementare


@@ -1622,9 +1621,45 @@ 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 manipolatore, in questo caso
 l'esecuzione non riprenderà nel manipolatore in questione, ma nel ciclo
 non viene gestita correttamente l'interazione con gli altri segnali; se
 infatti il segnale di allarme interrompe un altro manipolatore, in questo caso
 l'esecuzione non riprenderà nel manipolatore in questione, ma nel ciclo

-principale, interrompendone inopportunamente l'esecuzione.  È per questo
-motivo che occorrono funzioni più sofisticate della semplice \func{signal} che
-permettano di gestire i segnali in maniera più completa.
+principale, interrompendone inopportunamente l'esecuzione.  
+
+Lo stesso tipo di problema si presenterebbe se si volesse usare \func{alarm}
+per stabilire un timeout su una sistem call bloccante. Un secondo esempio è
+quello in cui si usa il segnale per notificare una quelche forma di evento; in
+genere quello che si fa in questo caso è settare nel manipolatore un opportuno
+flag da controllare nel corpo principale del programma (con un codice del tipo
+di quello riportato in 
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}{}
+sig_atomic_t flag;
+unsigned int control(unsigned int seconds)
+{
+    da fare
+}
+void alarm_hand(int sig) 
+{
+    /* set the flag 
+    flag = 1;
+}      
+    \end{lstlisting}
+  \end{minipage} 
+  \normalsize 
+  \caption{Un esempio non funzionante di restituzione di un evento da parte di
+    un segnale.} 
+  \label{fig:sig_event_wrong}
+\end{figure}
+
+
+
+È per questo motivo che occorrono funzioni più sofisticate della semplice
+\func{signal} che permettano di gestire i segnali in maniera più completa.
+
+
+
+

 
 
 \subsection{I \textit{signal set}}
 
 
 \subsection{I \textit{signal set}}


@@ -1812,20 +1847,20 @@ segnali; i valori possibili ed il relativo significato sono riportati in
 \end{table}
 
 Benché sia possibile usare nello stesso programma sia \func{sigaction} che
 \end{table}
 
 Benché sia possibile usare nello stesso programma sia \func{sigaction} che

-\func{signal} occorre comunque stare attenti, in quanto le due funzioni
-possono interagire in maniera anomala. In generale infatti l'azione
-specificata da \var{sigaction} contiene un maggior numero di informazioni
-rispetto al semplice indirizzo del manipolatore restituito da \func{signal}.
-Per questo motivo se si usa quest'ultima per installare un manipolatore
-sostituendone uno precedentemente installato con \func{sigaction}, non sarà
-possibile effettuare il ripristino dello stesso con il valore di ritorno.
-
-Per questo motivo è sempre il caso di usare \func{sigaction}, che è in grado
-di ripristinare correttamente un manipolatore precedente, anche se questo è
-stato installato con \func{signal}. In generale poi non è il caso di usare il
-valore di ritorno di \func{signal} come campo \var{sa\_handler}, o viceversa,
-dato che in certi sistemi questi possono essere diversi. In generale dunque, a
-meno che non si sia vincolati allo standard ISO C, è sempre il caso di evitare
+\func{signal} occorre molta attenzione, in quanto le due funzioni possono
+interagire in maniera anomala. Infatti l'azione specificata con
+\var{sigaction} contiene un maggior numero di informazioni rispetto al
+semplice indirizzo del manipolatore restituito da \func{signal}.  Per questo
+motivo se si usa quest'ultima per installare un manipolatore sostituendone uno
+precedentemente installato con \func{sigaction}, non sarà possibile effettuare
+un ripristino corretto dello stesso.
+
+Per questo è sempre opportuno usare \func{sigaction}, che è in grado di
+ripristinare correttamente un manipolatore precedente, anche se questo è stato
+installato con \func{signal}. In generale poi non è il caso di usare il valore
+di ritorno di \func{signal} come campo \var{sa\_handler}, o viceversa, dato
+che in certi sistemi questi possono essere diversi. In generale dunque, a meno
+che non si sia vincolati allo standard ISO C, è sempre il caso di evitare

 l'uso di \func{signal} a favore di \func{sigaction}.
 
 
 l'uso di \func{signal} a favore di \func{sigaction}.
 
 


@@ -1833,13 +1868,19 @@ l'uso di \func{signal} a favore di \func{sigaction}.
 \subsection{La gestione del blocco dei segnali}
 \label{sec:sig_sigmask}
 
 \subsection{La gestione del blocco dei segnali}
 \label{sec:sig_sigmask}
 

-Una delle informazioni che ciascun processo porta con se è l'insieme dei
-segnali bloccati (la cosiddetta \textit{signal mask}, anch'essa un signal set,
-mantenuta nel campo \var{blocked} di \var{task\_struct}); abbiamo accennato in
-\secref{sec:proc_fork} che essa viene ereditata alla creazione di un processo
-figlio, e abbiamo visto come essa viene controllata dal campo \var{sa\_mask}
-di \var{sigaction}.
-
+Come spiegato in \secref{sec:sig_semantics} tutti i moderni sistemi unix-like
+permettono si bloccare temporaneamente (o di eliminare completamente, settando
+\macro{SIG\_IGN} come azione) la consegna dei segnali ad un processo. Questo è
+fatto specificando la cosiddetta \textit{signal mask} del
+processo\footnote{nel caso di Linux essa è mantenuta dal campo \var{blocked}
+  della relativa \var{task\_struct}} che viene espressa come il signal set dei
+segnali la cui consegna è bloccata. Abbiamo accennato in
+\secref{sec:proc_fork} che la \textit{signal mask} viene ereditata dal padre
+alla creazione di un processo figlio, e abbiamo visto al paragrafo precedente
+che essa può essere specificata, durante l'esecuzione di un manipolatore,
+attraverso l'uso dal campo \var{sa\_mask} di \var{sigaction}.
+
+Uno dei problemi evidenziatisi con l'esempio di