From: Simone Piccardi Date: Tue, 9 Apr 2002 22:29:40 +0000 (+0000) Subject: Risistemazioni varie, lavori in corso X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=commitdiff_plain;h=2fbc954b9f4f62f19fa3409512ecdcb87c05350c Risistemazioni varie, lavori in corso --- diff --git a/signal.tex b/signal.tex index 1f0649d..966e32a 100644 --- 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: -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