Altre correzioni di indicizzazioni. Introdotta mremap. Aggiornati i flag di

[gapil.git] / signal.tex

diff --git a/signal.tex b/signal.tex
index 3adaee33b9f00e05307f202e53e70a206cf49a1d..66485bbcb2a63eeb751b91ef4390898b59e89ada 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -116,7 +116,7 @@ verr
 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 race condition\index{\textit{race~condition}}
+sono sempre possibili delle \textit{race condition}\itindex{race~condition}

 (sull'argomento vedi quanto detto in sez.~\ref{sec:proc_multi_prog}).
 
 Un altro problema è che in questa semantica non esiste un modo per bloccare i
 (sull'argomento vedi quanto detto in sez.~\ref{sec:proc_multi_prog}).
 
 Un altro problema è che in questa semantica non esiste un modo per bloccare i


@@ -136,7 +136,7 @@ Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
 \textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
 per tutto il tempo che passa fra la generazione del segnale e la sua consegna
 esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
 \textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
 per tutto il tempo che passa fra la generazione del segnale e la sua consegna
 esso è detto \textsl{pendente} (o \textit{pending}). In genere questa

-procedura viene effettuata dallo scheduler\index{\textit{scheduler}} quando,
+procedura viene effettuata dallo scheduler\itindex{scheduler} quando,

 riprendendo l'esecuzione del processo in questione, verifica la presenza del
 segnale nella \struct{task\_struct} e mette in esecuzione il gestore.
 
 riprendendo l'esecuzione del processo in questione, verifica la presenza del
 segnale nella \struct{task\_struct} e mette in esecuzione il gestore.
 


@@ -209,9 +209,9 @@ ignorarlo).
 
 Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
 avviene non appena questo viene rimesso in esecuzione dallo
 
 Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
 avviene non appena questo viene rimesso in esecuzione dallo

-scheduler\index{\textit{scheduler}} che esegue l'azione specificata. Questo a
-meno che il segnale in questione non sia stato bloccato prima della notifica,
-nel qual caso l'invio non avviene ed il segnale resta \textsl{pendente}
+scheduler\itindex{scheduler} che esegue l'azione specificata. Questo a meno
+che il segnale in questione non sia stato bloccato prima della notifica, nel
+qual caso l'invio non avviene ed il segnale resta \textsl{pendente}

 indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
 notificato. Si tenga presente però che i segnali \textsl{pendenti} non si
 accodano, alla generazione infatti il kernel marca un flag nella
 indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
 notificato. Si tenga presente però che i segnali \textsl{pendenti} non si
 accodano, alla generazione infatti il kernel marca un flag nella


@@ -241,11 +241,11 @@ una  delle tre possibilit
 
 Un programma può specificare queste scelte usando le due funzioni
 \func{signal} e \func{sigaction} (vedi sez.~\ref{sec:sig_signal} e
 
 Un programma può specificare queste scelte usando le due funzioni
 \func{signal} e \func{sigaction} (vedi 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 race
-condition\index{\textit{race~condition}}).
+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 \textit{race
+  condition}\itindex{race~condition}).

 
 Nel caso non sia stata specificata un'azione, viene utilizzata l'azione
 standard che (come vedremo in sez.~\ref{sec:sig_standard}) è propria di ciascun
 
 Nel caso non sia stata specificata un'azione, viene utilizzata l'azione
 standard che (come vedremo in sez.~\ref{sec:sig_standard}) è propria di ciascun


@@ -260,10 +260,11 @@ un eventuale messaggio di errore.
 
 I segnali che rappresentano errori del programma (divisione per zero o
 violazioni di accesso) hanno anche la caratteristica di scrivere un file di
 
 I segnali che rappresentano errori del programma (divisione per zero o
 violazioni di accesso) hanno anche la caratteristica di scrivere un file di

-\textit{core dump} che registra lo stato del processo (ed in particolare della
-memoria e dello stack) prima della terminazione.  Questo può essere esaminato
-in seguito con un debugger per investigare sulla causa dell'errore.  Lo stesso
-avviene se i suddetti segnali vengono generati con una \func{kill}.
+\itindex{core~dump}\textit{core dump} che registra lo stato del processo (ed
+in particolare della memoria e dello stack) prima della terminazione.  Questo
+può essere esaminato in seguito con un debugger per investigare sulla causa
+dell'errore.  Lo stesso avviene se i suddetti segnali vengono generati con una
+\func{kill}.

 
 
 \section{La classificazione dei segnali}
 
 
 \section{La classificazione dei segnali}


@@ -346,8 +347,9 @@ colonna standard sono stati indicati anche gli standard in cui ciascun segnale
 In alcuni casi alla terminazione del processo è associata la creazione di un
 file (posto nella directory corrente del processo e chiamato \file{core}) su
 cui viene salvata un'immagine della memoria del processo (il cosiddetto
 In alcuni casi alla terminazione del processo è associata la creazione di un
 file (posto nella directory corrente del processo e chiamato \file{core}) su
 cui viene salvata un'immagine della memoria del processo (il cosiddetto

-\textit{core dump}), che può essere usata da un debugger per esaminare lo
-stato dello stack e delle variabili al momento della ricezione del segnale.
+\itindex{core~dump}\textit{core dump}), che può essere usata da un debugger
+per esaminare lo stato dello stack e delle variabili al momento della
+ricezione del segnale.

 
 \begin{table}[htb]
   \footnotesize
 
 \begin{table}[htb]
   \footnotesize


@@ -415,11 +417,11 @@ tipologia, verr
 \label{sec:sig_prog_error}
 
 Questi segnali sono generati quando il sistema, o in certi casi direttamente
 \label{sec:sig_prog_error}
 
 Questi segnali sono generati quando il sistema, o in certi casi direttamente

-l'hardware (come per i \textit{page fault} non validi) rileva un qualche
-errore insanabile nel programma in esecuzione. In generale la generazione di
-questi segnali significa che il programma ha dei gravi problemi (ad esempio ha
-dereferenziato un puntatore non valido o ha eseguito una operazione aritmetica
-proibita) e l'esecuzione non può essere proseguita.
+l'hardware (come per i \itindex{page~fault}\textit{page fault} non validi)
+rileva un qualche errore insanabile nel programma in esecuzione. In generale
+la generazione di questi segnali significa che il programma ha dei gravi
+problemi (ad esempio ha dereferenziato un puntatore non valido o ha eseguito
+una operazione aritmetica proibita) e l'esecuzione non può essere proseguita.

 
 In genere si intercettano questi segnali per permettere al programma di
 terminare in maniera pulita, ad esempio per ripristinare le impostazioni della
 
 In genere si intercettano questi segnali per permettere al programma di
 terminare in maniera pulita, ad esempio per ripristinare le impostazioni della


@@ -431,10 +433,10 @@ gestore non ci fosse stato.
 
 L'azione predefinita per tutti questi segnali è causare la terminazione del
 processo che li ha causati. In genere oltre a questo il segnale provoca pure
 
 L'azione predefinita per tutti questi segnali è causare la terminazione del
 processo che li ha causati. In genere oltre a questo il segnale provoca pure

-la registrazione su disco di un file di \textit{core dump} che viene scritto
-in un file \file{core} nella directory corrente del processo al momento
-dell'errore, che il debugger può usare per ricostruire lo stato del programma
-al momento della terminazione.  Questi segnali sono:
+la registrazione su disco di un file di \itindex{core~dump}\textit{core dump}
+che viene scritto in un file \file{core} nella directory corrente del processo
+al momento dell'errore, che il debugger può usare per ricostruire lo stato del
+programma al momento della terminazione.  Questi segnali sono:

 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\const{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome
   derivi da \textit{floating point exception} si applica a tutti gli errori
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\const{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome
   derivi da \textit{floating point exception} si applica a tutti gli errori


@@ -515,7 +517,8 @@ segnali sono:
 \item[\const{SIGQUIT}] È analogo a \const{SIGINT} con la differenza che è
   controllato da un altro carattere di controllo, QUIT, corrispondente alla
   sequenza \verb|C-\|. A differenza del precedente l'azione predefinita, oltre
 \item[\const{SIGQUIT}] È analogo a \const{SIGINT} con la differenza che è
   controllato da un altro carattere di controllo, QUIT, corrispondente alla
   sequenza \verb|C-\|. A differenza del precedente l'azione predefinita, oltre

-  alla terminazione del processo, comporta anche la creazione di un core dump.
+  alla terminazione del processo, comporta anche la creazione di un
+  \itindex{core~dump}\textit{core dump}.

 
   In genere lo si può pensare come corrispondente ad una condizione di
   errore del programma rilevata dall'utente. Per questo motivo non è opportuno
 
   In genere lo si può pensare come corrispondente ad una condizione di
   errore del programma rilevata dall'utente. Per questo motivo non è opportuno


@@ -1354,12 +1357,11 @@ Chiaramente, anche se il tempo pu
 nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
 temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
 specificato, ma prima che il processo possa tornare ad essere eseguito
 nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
 temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
 specificato, ma prima che il processo possa tornare ad essere eseguito

-occorrerà almeno attendere il successivo giro di
-scheduler\index{\textit{scheduler}} e cioè un tempo che a seconda dei casi può
-arrivare fino a 1/\const{HZ}, (sempre che il sistema sia scarico ed il
-processa venga immediatamente rimesso in esecuzione); per questo motivo il
-valore restituito in \param{rem} è sempre arrotondato al multiplo successivo
-di 1/\const{HZ}.
+occorrerà almeno attendere il successivo giro di scheduler\itindex{scheduler}
+e cioè un tempo che a seconda dei casi può arrivare fino a 1/\const{HZ},
+(sempre che il sistema sia scarico ed il processa venga immediatamente rimesso
+in esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
+arrotondato al multiplo successivo di 1/\const{HZ}.

 
 In realtà è possibile ottenere anche pause più precise del centesimo di
 secondo usando politiche di scheduling real-time come \const{SCHED\_FIFO} o
 
 In realtà è possibile ottenere anche pause più precise del centesimo di
 secondo usando politiche di scheduling real-time come \const{SCHED\_FIFO} o


@@ -1451,8 +1453,8 @@ 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 race
-condition\index{\textit{race~condition}} che i segnali possono generare e alla
+considerazione le tematiche più complesse, collegate alle varie \textit{race
+  condition}\itindex{race~condition} che i segnali possono generare e alla

 natura asincrona degli stessi.
 
 Affronteremo queste problematiche in questa sezione, partendo da un esempio
 natura asincrona degli stessi.
 
 Affronteremo queste problematiche in questa sezione, partendo da un esempio


@@ -1494,14 +1496,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 race condition\index{\textit{race~condition}}.
+presenta una pericolosa \textit{race condition}\itindex{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 \const{SIGALRM}. In questo caso ci si
 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 \const{SIGALRM}. In questo caso ci si

-troverebbe di fronte ad un deadlock\index{\textit{deadlock}}, in quanto
-\func{pause} non verrebbe mai più interrotta (se non in caso di un altro
-segnale).
+troverebbe di fronte ad un deadlock\itindex{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


@@ -1558,7 +1559,7 @@ segnale, e prendere le relative azioni conseguenti (\texttt{\small 6-11}).
 
 Questo è il tipico esempio di caso, già citato in
 sez.~\ref{sec:proc_race_cond}, in cui si genera una
 
 Questo è il tipico esempio di caso, già citato in
 sez.~\ref{sec:proc_race_cond}, in cui si genera una

-\index{\textit{race~condition}}race condition; infatti, in una situazione in
+\itindex{race~condition}\textit{race condition}; infatti, in una situazione in

 cui un segnale è già arrivato (e \var{flag} è già ad 1) se un altro segnale
 segnale arriva immediatamente dopo l'esecuzione del controllo (\texttt{\small
   6}) ma prima della cancellazione del flag (\texttt{\small 7}), la sua
 cui un segnale è già arrivato (e \var{flag} è già ad 1) se un altro segnale
 segnale arriva immediatamente dopo l'esecuzione del controllo (\texttt{\small
   6}) ma prima della cancellazione del flag (\texttt{\small 7}), la sua


@@ -1575,7 +1576,8 @@ reagire alla ricezione di un segnale.
 \subsection{Gli \textsl{insiemi di segnali} o \textit{signal set}}
 \label{sec:sig_sigset}
 
 \subsection{Gli \textsl{insiemi di segnali} o \textit{signal set}}
 \label{sec:sig_sigset}
 

-\index{\textit{signal~set}|(} 
+\itindbeg{signal~set} 
+

 Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali
 originarie, nate con la semantica inaffidabile, hanno dei limiti non
 superabili; in particolare non è prevista nessuna funzione che permetta di
 Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali
 originarie, nate con la semantica inaffidabile, hanno dei limiti non
 superabili; in particolare non è prevista nessuna funzione che permetta di


@@ -1637,8 +1639,8 @@ ottenuto con \func{sigemptyset} o togliendo quelli che non servono da un
 insieme completo ottenuto con \func{sigfillset}. Infine \func{sigismember}
 permette di verificare la presenza di uno specifico segnale in un
 insieme.
 insieme completo ottenuto con \func{sigfillset}. Infine \func{sigismember}
 permette di verificare la presenza di uno specifico segnale in un
 insieme.

-\index{\textit{signal~set}|)}

 
 

+\itindend{signal~set} 

 
 
 \subsection{La funzione \func{sigaction}}
 
 
 \subsection{La funzione \func{sigaction}}


@@ -1871,7 +1873,7 @@ estremamente semplice, 
   \textit{signal mask}}
 \label{sec:sig_sigmask}
 
   \textit{signal mask}}
 \label{sec:sig_sigmask}
 

-\index{\textit{signal mask}|(}
+\itindbeg{signal~mask}

 Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like
 permettono di bloccare temporaneamente (o di eliminare completamente,
 impostando \const{SIG\_IGN} come azione) la consegna dei segnali ad un
 Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like
 permettono di bloccare temporaneamente (o di eliminare completamente,
 impostando \const{SIG\_IGN} come azione) la consegna dei segnali ad un


@@ -1949,7 +1951,7 @@ occorre ricordare che qualunque modifica alla maschera dei segnali viene
 perduta alla conclusione del terminatore. 
 
 Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
 perduta alla conclusione del terminatore. 
 
 Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte

-dei casi di race condition\index{\textit{race~condition}} restano aperte
+dei casi di \textit{race condition}\itindex{race~condition} restano aperte

 alcune possibilità legate all'uso di \func{pause}; il caso è simile a quello
 del problema illustrato nell'esempio di fig.~\ref{fig:sig_sleep_incomplete}, e
 cioè la possibilità che il processo riceva il segnale che si intende usare per
 alcune possibilità legate all'uso di \func{pause}; il caso è simile a quello
 del problema illustrato nell'esempio di fig.~\ref{fig:sig_sleep_incomplete}, e
 cioè la possibilità che il processo riceva il segnale che si intende usare per


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

-In questo modo non sono più possibili race
-condition\index{\textit{race~condition}} dato che \const{SIGALRM} viene
+In questo modo non sono più possibili \textit{race
+  condition}\itindex{race~condition} dato che \const{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
 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


@@ -2023,9 +2025,10 @@ i seguenti:
 \end{enumerate*}
 Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi
 riabilitarla immediatamente dopo, in questo modo si evita il
 \end{enumerate*}
 Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi
 riabilitarla immediatamente dopo, in questo modo si evita il

-deadlock\index{\textit{deadlock}} dovuto all'arrivo del segnale prima
-dell'esecuzione di \func{sigsuspend}.
-\index{\textit{signal mask}|)}
+deadlock\itindex{deadlock} dovuto all'arrivo del segnale prima dell'esecuzione
+di \func{sigsuspend}.  
+
+\itindend{signal~mask}

 
 
 \subsection{Ulteriori funzioni di gestione}
 
 
 \subsection{Ulteriori funzioni di gestione}