Altre indicizzazioni e recupero dei pezzi tagliati per sbaglio

[gapil.git] / signal.tex

diff --git a/signal.tex b/signal.tex
index 493bf4460479e0a99b737de9537db9535557c400..bde6dfcedc1619d500a0a1e99b5f7cd015b7585e 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -115,20 +115,20 @@ gestore non verrebbe eseguita.
 Questa è la ragione per cui l'implementazione dei segnali secondo questa
 semantica viene chiamata \textsl{inaffidabile}: infatti la ricezione del
 segnale e la reinstallazione del suo gestore non sono operazioni atomiche, e
 Questa è la ragione per cui l'implementazione dei segnali secondo questa
 semantica viene chiamata \textsl{inaffidabile}: infatti la ricezione del
 segnale e la reinstallazione del suo gestore non sono operazioni atomiche, e

-sono sempre possibili delle \itindex{race~condition} \textit{race condition}
-(si ricordi sez.~\ref{sec:proc_multi_prog}).  Un altro problema è che in
-questa semantica non esiste un modo per bloccare i segnali quando non si vuole
-che arrivino; i processi possono ignorare il segnale, ma non è possibile
-istruire il sistema a non fare nulla in occasione di un segnale, pur
-mantenendo memoria del fatto che è avvenuto.
+sono sempre possibili delle \textit{race condition} (si ricordi
+sez.~\ref{sec:proc_multi_prog}).  Un altro problema è che in questa semantica
+non esiste un modo per bloccare i segnali quando non si vuole che arrivino; i
+processi possono ignorare il segnale, ma non è possibile istruire il sistema a
+non fare nulla in occasione di un segnale, pur mantenendo memoria del fatto
+che è avvenuto.

 
 Nella semantica \textsl{affidabile} (quella utilizzata da Linux e da ogni Unix
 moderno) il gestore una volta installato resta attivo e non si hanno tutti i
 problemi precedenti. In questa semantica i segnali vengono \textsl{generati}
 dal kernel per un processo all'occorrenza dell'evento che causa il segnale. In
 genere questo viene fatto dal kernel impostando un apposito campo della
 
 Nella semantica \textsl{affidabile} (quella utilizzata da Linux e da ogni Unix
 moderno) il gestore una volta installato resta attivo e non si hanno tutti i
 problemi precedenti. In questa semantica i segnali vengono \textsl{generati}
 dal kernel per un processo all'occorrenza dell'evento che causa il segnale. In
 genere questo viene fatto dal kernel impostando un apposito campo della

-\struct{task\_struct} del processo nella \itindex{process~table}
-\textit{process table} (si veda fig.~\ref{fig:proc_task_struct}).
+\struct{task\_struct} del processo nella \textit{process table} (si veda
+fig.~\ref{fig:proc_task_struct}).

 
 Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
 \textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
 
 Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
 \textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre


@@ -258,7 +258,7 @@ sez.~\ref{sec:sig_signal} e sez.~\ref{sec:sig_sigaction}. Se si è installato
 un gestore sarà quest'ultimo ad essere eseguito alla notifica del segnale.
 Inoltre il sistema farà si che mentre viene eseguito il gestore di un segnale,
 quest'ultimo venga automaticamente bloccato, così si possono evitare alla
 un gestore sarà quest'ultimo ad essere eseguito alla notifica del segnale.
 Inoltre il sistema farà si che mentre viene eseguito il gestore di un segnale,
 quest'ultimo venga automaticamente bloccato, così si possono evitare alla

-radice possibili \itindex{race~condition} \textit{race condition}.
+radice possibili \textit{race condition}.

 
 Nel caso non sia stata specificata un'azione, viene utilizzata la cosiddetta
 azione predefinita che, come vedremo in sez.~\ref{sec:sig_standard}, è propria
 
 Nel caso non sia stata specificata un'azione, viene utilizzata la cosiddetta
 azione predefinita che, come vedremo in sez.~\ref{sec:sig_standard}, è propria


@@ -1675,13 +1675,13 @@ generale dunque, quando non interessa elaborare lo stato di uscita di un
 processo, si può completare la gestione della terminazione installando un
 gestore per \signal{SIGCHLD} il cui unico compito sia quello di chiamare
 \func{waitpid} per completare la procedura di terminazione in modo da evitare
 processo, si può completare la gestione della terminazione installando un
 gestore per \signal{SIGCHLD} il cui unico compito sia quello di chiamare
 \func{waitpid} per completare la procedura di terminazione in modo da evitare

-la formazione di \itindex{zombie} \textit{zombie}.\footnote{si ricordi
-  comunque che dal kernel 2.6 seguendo lo standard POSIX.1-2001 per evitare di
-  dover ricevere gli stati di uscita che non interessano basta impostare come
-  azione predefinita quella di ignorare \signal{SIGCHLD}, nel qual caso viene
-  assunta la semantica di System V, in cui il segnale non viene inviato, il
-  sistema non genera \itindex{zombie} \textit{zombie} e lo stato di
-  terminazione viene scartato senza dover chiamare una \func{wait}.}
+la formazione di \textit{zombie}.\footnote{si ricordi comunque che dal kernel
+  2.6 seguendo lo standard POSIX.1-2001 per evitare di dover ricevere gli
+  stati di uscita che non interessano basta impostare come azione predefinita
+  quella di ignorare \signal{SIGCHLD}, nel qual caso viene assunta la
+  semantica di System V, in cui il segnale non viene inviato, il sistema non
+  genera \textit{zombie} e lo stato di terminazione viene scartato senza dover
+  chiamare una \func{wait}.}

 
 In fig.~\ref{fig:sig_sigchld_handl} è mostrato il codice contenente una
 implementazione generica di una funzione di gestione per \signal{SIGCHLD},
 
 In fig.~\ref{fig:sig_sigchld_handl} è mostrato il codice contenente una
 implementazione generica di una funzione di gestione per \signal{SIGCHLD},


@@ -1689,7 +1689,7 @@ implementazione generica di una funzione di gestione per \signal{SIGCHLD},
 test di sez.~\ref{sec:proc_termination}, invocando \cmd{forktest} con
 l'opzione \cmd{-s} (che si limita ad effettuare l'installazione di questa
 funzione come gestore di \signal{SIGCHLD}) potremo verificare che non si ha
 test di sez.~\ref{sec:proc_termination}, invocando \cmd{forktest} con
 l'opzione \cmd{-s} (che si limita ad effettuare l'installazione di questa
 funzione come gestore di \signal{SIGCHLD}) potremo verificare che non si ha

-più la creazione di \itindex{zombie} \textit{zombie}.
+più la creazione di \textit{zombie}.

 
 \begin{figure}[!htbp]
   \footnotesize  \centering
 
 \begin{figure}[!htbp]
   \footnotesize  \centering


@@ -1730,8 +1730,7 @@ rimosso verrà recapitato un solo segnale.
 Allora, nel caso della terminazione dei processi figli, se si chiamasse
 \func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un
 solo processo, anche se i processi terminati sono più di uno, e gli altri
 Allora, nel caso della terminazione dei processi figli, se si chiamasse
 \func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un
 solo processo, anche se i processi terminati sono più di uno, e gli altri

-resterebbero in stato di \itindex{zombie} \textit{zombie} per un tempo
-indefinito.
+resterebbero in stato di \textit{zombie} per un tempo indefinito.

 
 Per questo occorre ripetere la chiamata di \func{waitpid} fino a che essa non
 ritorni un valore nullo, segno che non resta nessun processo di cui si debba
 
 Per questo occorre ripetere la chiamata di \func{waitpid} fino a che essa non
 ritorni un valore nullo, segno che non resta nessun processo di cui si debba


@@ -1747,9 +1746,9 @@ tutti gli stati di terminazione sono stati ricevuti.
 
 Le funzioni esaminate finora fanno riferimento alle modalità più elementari
 della gestione dei segnali; non si sono pertanto ancora prese in
 
 Le funzioni esaminate finora fanno riferimento alle modalità più elementari
 della gestione dei segnali; non si sono pertanto ancora prese in

-considerazione le tematiche più complesse, collegate alle varie
-\itindex{race~condition} \textit{race condition} che i segnali possono
-generare e alla natura asincrona degli stessi.
+considerazione le tematiche più complesse, collegate alle varie \textit{race
+  condition} che i segnali possono generare e alla natura asincrona degli
+stessi.

 
 Affronteremo queste problematiche in questa sezione, partendo da un esempio
 che le evidenzi, per poi prendere in esame le varie funzioni che permettono di
 
 Affronteremo queste problematiche in questa sezione, partendo da un esempio
 che le evidenzi, per poi prendere in esame le varie funzioni che permettono di


@@ -1790,13 +1789,13 @@ l'interruzione di \func{pause} venisse causata da un altro segnale.
 
 Questo codice però, a parte il non gestire il caso in cui si è avuta una
 precedente chiamata a \func{alarm} (che si è tralasciato per brevità),
 
 Questo codice però, a parte il non gestire il caso in cui si è avuta una
 precedente chiamata a \func{alarm} (che si è tralasciato per brevità),

-presenta una pericolosa \itindex{race~condition} \textit{race condition}.
-Infatti, se il processo viene interrotto fra la chiamata di \func{alarm} e
-\func{pause}, può capitare (ad esempio se il sistema è molto carico) che il
-tempo di attesa scada prima dell'esecuzione di quest'ultima, cosicché essa
-sarebbe eseguita dopo l'arrivo di \signal{SIGALRM}. In questo caso ci si
-troverebbe di fronte ad un \itindex{deadlock} deadlock, in quanto \func{pause}
-non verrebbe mai più interrotta (se non in caso di un altro segnale).
+presenta una pericolosa \textit{race condition}.  Infatti, se il processo
+viene interrotto fra la chiamata di \func{alarm} e \func{pause}, può capitare
+(ad esempio se il sistema è molto carico) che il tempo di attesa scada prima
+dell'esecuzione di quest'ultima, cosicché essa sarebbe eseguita dopo l'arrivo
+di \signal{SIGALRM}. In questo caso ci si troverebbe di fronte ad un
+\textit{deadlock}, in quanto \func{pause} non verrebbe mai più interrotta (se
+non in caso di un altro segnale).

 
 Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
 SVr2) usando la funzione \func{longjmp} (vedi sez.~\ref{sec:proc_longjmp}) per
 
 Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
 SVr2) usando la funzione \func{longjmp} (vedi sez.~\ref{sec:proc_longjmp}) per


@@ -1854,12 +1853,12 @@ l'occorrenza o meno del segnale, ed eseguire le azioni conseguenti
 \end{figure}
 
 Questo è il tipico esempio di caso, già citato in
 \end{figure}
 
 Questo è il tipico esempio di caso, già citato in

-sez.~\ref{sec:proc_race_cond}, in cui si genera una \itindex{race~condition}
-\textit{race condition}. Infatti, in una situazione in cui un segnale è già
-arrivato (e quindi \var{flag} è già stata impostata ad 1 nel gestore) se un
-altro segnale arriva immediatamente dopo l'esecuzione del controllo
-(\texttt{\small 6}) ma prima della cancellazione di \var{flag} fatta subito
-dopo (\texttt{\small 7}), la sua occorrenza sarà perduta.
+sez.~\ref{sec:proc_race_cond}, in cui si genera una \textit{race
+  condition}. Infatti, in una situazione in cui un segnale è già arrivato (e
+quindi \var{flag} è già stata impostata ad 1 nel gestore) se un altro segnale
+arriva immediatamente dopo l'esecuzione del controllo (\texttt{\small 6}) ma
+prima della cancellazione di \var{flag} fatta subito dopo (\texttt{\small 7}),
+la sua occorrenza sarà perduta.

 
 Questi esempi ci mostrano come per poter eseguire una gestione effettiva dei
 segnali occorrono delle funzioni più sofisticate di quelle finora
 
 Questi esempi ci mostrano come per poter eseguire una gestione effettiva dei
 segnali occorrono delle funzioni più sofisticate di quelle finora


@@ -2099,13 +2098,13 @@ tab.~\ref{tab:sig_sa_flag}.
                            quando si imposta un gestore per \signal{SIGCHLD}.\\
     \const{SA\_NOCLDWAIT}& Se il segnale è \signal{SIGCHLD} e si richiede di
                            ignorare il segnale con \const{SIG\_IGN} allora i
                            quando si imposta un gestore per \signal{SIGCHLD}.\\
     \const{SA\_NOCLDWAIT}& Se il segnale è \signal{SIGCHLD} e si richiede di
                            ignorare il segnale con \const{SIG\_IGN} allora i

-                           processi figli non diventano \itindex{zombie}
-                           \textit{zombie} quando terminano; questa
-                           funzionalità è stata introdotta nel kernel 2.6 e va
-                           a modificare il comportamento di \func{waitpid}
-                           come illustrato in sez.~\ref{sec:proc_wait}, se si
-                           installa un gestore con questo flag attivo il
-                           segnale \signal{SIGCHLD} viene comunque generato.\\ 
+                           processi figli non diventano \textit{zombie} quando
+                           terminano; questa funzionalità è stata introdotta
+                           nel kernel 2.6 e va a modificare il comportamento
+                           di \func{waitpid} come illustrato in
+                           sez.~\ref{sec:proc_wait}, se si installa un gestore
+                           con questo flag attivo il segnale \signal{SIGCHLD}
+                           viene comunque generato.\\

     \const{SA\_NODEFER}  & Evita che il segnale corrente sia bloccato durante
                            l'esecuzione del gestore.\\
     \const{SA\_NOMASK}   & Nome obsoleto e sinonimo non standard di
     \const{SA\_NODEFER}  & Evita che il segnale corrente sia bloccato durante
                            l'esecuzione del gestore.\\
     \const{SA\_NOMASK}   & Nome obsoleto e sinonimo non standard di


@@ -2518,11 +2517,11 @@ fine (\texttt{\small 22}), e al contempo si prepara la maschera dei segnali
 \var{sleep\_mask} per riattivare \signal{SIGALRM} all'esecuzione di
 \func{sigsuspend}.  
 
 \var{sleep\_mask} per riattivare \signal{SIGALRM} all'esecuzione di
 \func{sigsuspend}.  
 

-In questo modo non sono più possibili \itindex{race~condition} \textit{race
-  condition} dato che \signal{SIGALRM} viene disabilitato con
-\func{sigprocmask} fino alla chiamata di \func{sigsuspend}.  Questo metodo è
-assolutamente generale e può essere applicato a qualunque altra situazione in
-cui si deve attendere per un segnale, i passi sono sempre i seguenti:
+In questo modo non sono più possibili \textit{race condition} dato che
+\signal{SIGALRM} viene disabilitato con \func{sigprocmask} fino alla chiamata
+di \func{sigsuspend}.  Questo metodo è assolutamente generale e può essere
+applicato a qualunque altra situazione in cui si deve attendere per un
+segnale, i passi sono sempre i seguenti:

 \begin{enumerate*}
 \item leggere la maschera dei segnali corrente e bloccare il segnale voluto
   con \func{sigprocmask};
 \begin{enumerate*}
 \item leggere la maschera dei segnali corrente e bloccare il segnale voluto
   con \func{sigprocmask};


@@ -2531,9 +2530,8 @@ cui si deve attendere per un segnale, i passi sono sempre i seguenti:
 \item ripristinare la maschera dei segnali originaria.
 \end{enumerate*}
 Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi
 \item ripristinare la maschera dei segnali originaria.
 \end{enumerate*}
 Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi

-riabilitarla immediatamente dopo, in questo modo si evita il
-\itindex{deadlock} deadlock dovuto all'arrivo del segnale prima
-dell'esecuzione di \func{sigsuspend}.
+riabilitarla immediatamente dopo, in questo modo si evita il \textit{deadlock}
+dovuto all'arrivo del segnale prima dell'esecuzione di \func{sigsuspend}.

 
 \index{maschera dei segnali|)}
 
 
 \index{maschera dei segnali|)}