Modifiche e chiarimenti

[gapil.git] / signal.tex

diff --git a/signal.tex b/signal.tex
index 966e32a1aa0759a2d1d6b15210171c3f2680d5e7..b766ea6464574de019317ab94fa0f1661d00b0b4 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -1621,44 +1621,62 @@ 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.  
+principale, interrompendone inopportunamente l'esecuzione.  Lo stesso tipo di
+problemi si presenterebbero se si volesse usare \func{alarm} per stabilire un
+timeout su una qualunque system call bloccante.

 
 

-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 
+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
+\secref{fig:sig_event_wrong}.

 
 \begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{15cm}
     \begin{lstlisting}{}
 sig_atomic_t flag;
 
 \begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{15cm}
     \begin{lstlisting}{}
 sig_atomic_t flag;

-unsigned int control(unsigned int seconds)
+int main()

 {
 {

-    da fare
+    flag = 0;
+    ...
+    if (flag) {         /* test if signal occurred */
+        flag = 0;       /* reset flag */ 
+        do_response();  /* do things */
+    } else {
+        do_other();     /* do other things */
+    }
+    ...

 }
 void alarm_hand(int sig) 
 {
     /* set the flag 
     flag = 1;
 }
 void alarm_hand(int sig) 
 {
     /* set the flag 
     flag = 1;

+    return;

 }      
     \end{lstlisting}
   \end{minipage} 
   \normalsize 
 }      
     \end{lstlisting}
   \end{minipage} 
   \normalsize 

-  \caption{Un esempio non funzionante di restituzione di un evento da parte di
-    un segnale.} 
+  \caption{Un esempio non funzionante del codice per il controllo di un
+    evento generato da un segnale.}

   \label{fig:sig_event_wrong}
 \end{figure}
 
   \label{fig:sig_event_wrong}
 \end{figure}
 

+La logica è quella di far settare al manipolatore (\texttt{\small 14-19}) una
+variabile globale preventivamente inizializzata nel programma principale, il
+quale potrà determinare, osservandone il contenuto, l'occorrenza o meno del
+segnale, e prendere le relative azioni conseguenti (\texttt{\small 6-11}).

 
 

+Questo è il tipico esempio di caso, già citato in \secref{sec:proc_race_cond},
+in cui si genera una race condition; se infatti il segnale arriva
+immediatamente dopo l'esecuzione del controllo (\texttt{\small 6}) ma prima
+della cancellazione del flag (\texttt{\small 7}), la sua occorrenza sarà
+perduta.

 
 

-È per questo motivo che occorrono funzioni più sofisticate della semplice
-\func{signal} che permettano di gestire i segnali in maniera più completa.
-
-
-
+Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono
+funzioni più sofisticate della semplice interfaccia dei primi sistemi Unix,
+che permettano di gestire tutti i possibili aspetti con cui un processo deve
+reagire alla ricezione di un segnale.

 
 
 
 
 
 


@@ -1880,7 +1898,11 @@ 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}.
 
 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 
+Uno dei problemi evidenziatisi con l'esempio di \secref{fig:sig_event_wrong} è
+che in molti casi è necessario proteggere delle sezioni di codice (nel caso la
+sezione fra il test e la eventuale cancellazione del flag che testimoniava
+l'avvenuta occorrenza del segnale) in modo da essere sicuri che essi siano
+eseguiti senza interruzioni.