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).
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
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}}
\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}.
\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
projects / gapil.git / commitdiff