Risistemazioni varie, lavori in corso
authorSimone Piccardi <piccardi@gnulinux.it>
Tue, 9 Apr 2002 22:29:40 +0000 (22:29 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Tue, 9 Apr 2002 22:29:40 +0000 (22:29 +0000)
signal.tex

index 1f0649db98fba4f9895f8a0af72ca997c2b57234..966e32a1aa0759a2d1d6b15210171c3f2680d5e7 100644 (file)
@@ -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: 
-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).
@@ -1501,7 +1500,7 @@ fino a trattare le caratteristiche generali della gestione dei medesimi nella
 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
@@ -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
-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}}
@@ -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
-\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}.
 
 
@@ -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}
 
-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