Modifiche varie in ordine alla gestione dei segnali e di SIGCHLD
authorSimone Piccardi <piccardi@gnulinux.it>
Thu, 21 Mar 2002 00:43:36 +0000 (00:43 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Thu, 21 Mar 2002 00:43:36 +0000 (00:43 +0000)
network.tex
signal.tex
system.tex

index b1f825f61dca920a311ab38e6404271eb17bd26c..92e869f8ce42b4a30040d26fc8d22db38d69c249 100644 (file)
@@ -273,7 +273,7 @@ alcune dalle principali applicazioni che li usano.
 
 \begin{figure}[!htbp]
   \centering
-  \includegraphics[width=10cm]{img/tcpip_overview}  
+  \includegraphics[width=15cm]{img/tcpip_overview}  
   \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
   \label{fig:net_tcpip_overview}
 \end{figure}
index 1375a973649190628d95fe6a4cce2d8f48c9e411..0e1c42a1c850a29fb70ef7c7d0af6e5857887edd 100644 (file)
@@ -153,12 +153,6 @@ di un segnale, pur mantenendo memoria del fatto che 
 % chiamata a \func{pause}, nel qual caso, se il segnale non viene più generato,
 % il processo resterà in sleep permanentemente.
 
-% % Un'altra caratteristica della implementazione inaffidabile è che le chiamate
-% % di sistema non sono fatte ripartire automaticamente quando sono interrotte da
-% % un segnale, per questo un programma deve controllare lo stato di uscita della
-% % chiamata al sistema e ripeterla nel caso l'errore riportato da \texttt{errno}
-% % sia \texttt{EINTR}.
-
 % Questo ci mostra ad esempio come con la semantica inaffidabile non esista una
 % modalità semplice per ottenere una operazione di attesa mandando in stato di
 % sleep (vedi \ref{sec:proc_sched}) un processo fino all'arrivo di un segnale.
@@ -472,6 +466,9 @@ Questi segnali sono:
 \item[\macro{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome
   derivi da \textit{floating point exception} si applica a tutti gli errori
   aritmetici compresa la divisione per zero e l'overflow. 
+  
+  Se il manipolatore ritorna il comportamento del processo è indefinito, ed
+  ignorare questo segnale può condurre ad un loop infinito.
 
 %   Per questo segnale le cose sono complicate dal fatto che possono esserci
 %   molte diverse eccezioni che \texttt{SIGFPE} non distingue, mentre lo
@@ -487,12 +484,14 @@ Questi segnali sono:
   posto di un puntatore a funzione, o si eccede la scrittura di un vettore di
   una variabile locale, andando a corrompere lo stack. Lo stesso segnale viene
   generato in caso di overflow dello stack o di problemi nell'esecuzione di un
-  manipolatore.
+  manipolatore. Se il manipolatore ritorna il comportamento del processo è
+  indefinito.
 \item[\macro{SIGSEGV}] Il nome deriva da \textit{segment violation}, e
   significa che il programma sta cercando di leggere o scrivere in una zona di
   memoria protetta al di fuori di quella che gli è stata riservata dal
   sistema. In genere è il meccanismo della protezione della memoria che si
-  accorge dell'errore ed il kernel genera il segnale.
+  accorge dell'errore ed il kernel genera il segnale.  Se il manipolatore
+  ritorna il comportamento del processo è indefinito.
 
   È tipico ottenere questo segnale dereferenziando un puntatore nullo o non
   inizializzato leggendo al di la della fine di un vettore. 
@@ -1237,21 +1236,23 @@ il processo non viene terminato direttamente dal manipolatore sia la stessa
 \func{abort} a farlo al ritorno dello stesso. Inoltre, sempre seguendo lo
 standard POSIX, prima della terminazione tutti i file aperti e gli stream
 saranno chiusi ed i buffer scaricati su disco. Non verranno invece eseguite le
-funzioni registrate con \func{at\_exit} e \func{on\_exit}.
+eventuali funzioni registrate con \func{at\_exit} e \func{on\_exit}.
 
 
 \subsection{Le funzioni \func{pause} e \func{sleep}}
 \label{sec:sig_pause_sleep}
 
-Il metodo tradizionale per fare attendere ad un processo fino all'arrivo di un
-segnale è quello di usare la funzione \func{pause}, il cui prototipo è:
+Il metodo tradizionale per fare attendere\footnote{cioè di porre
+  temporanemente il processo in stato di \textit{sleep}, vedi
+  \ref{sec:proc_sched}.}  ad un processo fino all'arrivo di un segnale è
+quello di usare la funzione \func{pause}, il cui prototipo è:
 \begin{prototype}{unistd.h}{int pause(void)}
   
   Pone il processo in stato di sleep fino al ritorno di un manipolatore.
   
   \bodydesc{La funzione ritorna solo dopo che un segnale è stato ricevuto ed
-  il relativo manipolatore è ritornato, nel qual caso restituisce -1 e setta
-  \var{errno} a \macro{EINTR}.}
+    il relativo manipolatore è ritornato, nel qual caso restituisce -1 e setta
+    \var{errno} a \macro{EINTR}.}
 \end{prototype}
 
 La funzione segnala sempre una condizione di errore (il successo sarebbe
@@ -1260,10 +1261,9 @@ si vuole mettere un processo in attesa di un qualche evento specifico che non
 è sotto il suo diretto controllo (ad esempio la si può usare per far reagire
 il processo ad un segnale inviato da un altro processo).
 
-
 Se invece si vuole fare attendere un processo per un determinato intervallo di
-tempo lo standard POSIX.1 definisce la funzione \func{sleep}, il cui prototipo
-è:
+tempo nello standard POSIX.1 viene definita la funzione \func{sleep}, il cui
+prototipo è:
 \begin{prototype}{unistd.h}{unsigned int sleep(unsigned int seconds)}
   
   Pone il processo in stato di sleep per \param{seconds} secondi.
@@ -1277,13 +1277,14 @@ da un segnale. In questo caso non 
 tempo rimanente, in quanto la riattivazione del processo può avvenire in un
 qualunque momento, ma il valore restituito sarà sempre arrotondato al secondo,
 con la conseguenza che, se la successione dei segnali è particolarmente
-sfortunata, si potranno avere ritardi anche di parecchi secondi. In genere la
-scelta più sicura è quella di stabilire un termine per l'attesa, e ricalcolare
-tutte le volte il numero di secondi da aspettare.
+sfortunata e le differenze si accumulano, si potranno avere ritardi anche di
+parecchi secondi. In genere la scelta più sicura è quella di stabilire un
+termine per l'attesa, e ricalcolare tutte le volte il numero di secondi da
+aspettare.
 
 In alcune implementazioni inoltre l'uso di \func{sleep} può avere conflitti
-con quello di \macro{SIGALRM}, dato che la funzione può essere realizzata
-attraverso \func{pause} e \func{alarm} (in maniera analoga all'esempio che
+con quello di \macro{SIGALRM}, dato che la funzione può essere realizzata con
+l'uso di \func{pause} e \func{alarm} (in maniera analoga all'esempio che
 vedremo in \ref{sec:sig_example}). In tal caso mescolare chiamata di
 \func{alarm} e \func{sleep} o modificare l'azione di \macro{SIGALRM}, può
 causare risultati indefiniti. Nel caso delle \acr{glibc} è stata usata una
@@ -1294,7 +1295,7 @@ questo sia sotto BSD4.3 che in SUSv2 
 \func{usleep} (dove la \texttt{u} è intesa come sostituzione di $\mu$); i due
 standard hanno delle definizioni diverse, ma le \acr{glibc}
 seguono\footnote{secondo la man page almeno dalla versione 2.2.2.} seguono
-quella di SUSv2 che prevede il seguente prototipo: 
+quella di SUSv2 che prevede il seguente prototipo:
 \begin{prototype}{unistd.h}{int usleep(unsigned long usec)}
   
   Pone il processo in stato di sleep per \param{usec} microsecondi.
@@ -1304,10 +1305,10 @@ quella di SUSv2 che prevede il seguente prototipo:
 
 \end{prototype}
 
-Anche questa funzione a seconda delle implementazioni può presentare problemi
-nell'interazione con \func{alarm} e \macro{SIGALRM}, ed è pertanto deprecata
-in favore di \func{nanosleep}, definita dallo standard POSIX1.b, il cui
-prototipo è:
+Anche questa funzione, a seconda delle implementazioni, può presentare
+problemi nell'interazione con \func{alarm} e \macro{SIGALRM}. È pertanto
+deprecata in favore della funzione \func{nanosleep}, definita dallo standard
+POSIX1.b, il cui prototipo è:
 \begin{prototype}{unistd.h}{int nanosleep(const struct timespec *req, struct
     timespec *rem)}
   
@@ -1376,16 +1377,25 @@ Un semplice esempio per illustrare il funzionamento di un manipolatore di
 segnale è quello della gestione di \macro{SIGCHLD}. Abbiamo visto in
 \secref{sec:proc_termination} che una delle azioni eseguite dal kernel alla
 conclusione di un processo è quella di inviare questo segnale al
-padre;\footnote{in realtà in SRV4 eredita la semantica di System V, in cui il
+padre.\footnote{in realtà in SRV4 eredita la semantica di System V, in cui il
   segnale si chiama \macro{SIGCLD} e viene trattato in maniera speciale; in
   System V infatti se si setta esplicitamente l'azione a \macro{SIG\_IGN} il
   segnale non viene generato ed il sistema non genera zombie (lo stato di
   terminazione viene scartato senza dover chiamare una \func{wait}). L'azione
   di default è sempre quella di ignorare il segnale, ma non attiva questo
   comportamento. Linux, come BSD e POSIX, non supporta questa semantica ed usa
-  il nome di \macro{SIGCLD} come sinonimo di \macro{SIGCHLD}.} in questo caso
-tutto quello che dovrà fare il manipolatore è ricevere lo stato di
-terminazione in modo da evitare la formazione di zombie.
+  il nome di \macro{SIGCLD} come sinonimo di \macro{SIGCHLD}.} In generale
+dunque, quando non interessa elaborare lo stato di uscita di un processo, si
+può completare la gestione della terminazione installando un manipolatore per
+\macro{SIGCHLD} il cui unico compito sia quello chiamare \func{wait} per
+completare la procedura di terminazione in modo da evitare la formazione di
+zombie.
+
+In \figref{fig:sig_sigchld_handl} è mostrato il codice della nostra
+implementazione del manipolatore; se aggiungiamo al codice di
+\file{ForkTest.c} l'intallazione di questo manipolatore potremo verificare che
+ripetendo l'esempio visto in \secref{sec:proc_termination} che non si ha più
+la creazione di zombie.
 
 %  è pertanto
 % naturale usare un esempio che ci permette di concludere la trattazione della
@@ -1393,16 +1403,11 @@ terminazione in modo da evitare la formazione di zombie.
 % In questo caso si è tratterà di illustrare un esempio relativo ad un
 % manipolatore per che è previsto ritornare,
 
-In realtà nel caso di \macro{SIGCHLD} occorre tenere conto anche di un altro
-aspetto del comportamento dei segnali e cioè del fatto 
-
-
-
 
 \begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{15cm}
-    \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+    \begin{lstlisting}{}
 #include <errno.h>       /* error simbol definitions */
 #include <signal.h>      /* signal handling declarations */
 #include <sys/types.h>
@@ -1424,7 +1429,7 @@ void Hand_CHLD(int sig)
             debug("child %d terminated with status %x\n", pid, status);
         }
     } while ((pid > 0) && (errno == EINTR));
-    /* restore errno value*/
+    /* restore errno value */
     errno = errno_save;
     /* return */
     return;
@@ -1432,12 +1437,39 @@ void Hand_CHLD(int sig)
     \end{lstlisting}
   \end{minipage} 
   \normalsize 
-  \caption{Una implementazione sbagliata di \func{sleep}.} 
-  \label{fig:sig_timespec_def}
+  \caption{Un manipolatore per il segnale \texttt{SIGCHLD}.} 
+  \label{fig:sig_sigchld_handl}
 \end{figure}
 
-
-
+Il codice del manipolatore è di lettura immediata; come buona norma di
+programmazione (si ricordi quanto accennato \ref{sec:sys_errno}) si comincia
+(\texttt{\small 13}) con il salvare lo stato corrente di \var{errno}, in modo
+da poterla ripristinare prima del ritorno del manipolatore (\texttt{\small
+  23}). In questo modo si preserva il valore della variabile visto dal corso
+di esecuzione principale del processo, che sarebbe altrimenti sarebbe
+sovrascritto dal valore restituito nella successiva chiamata di \func{wait}.
+
+Il compito principale del manipolatore è quello di ricevere lo stato di
+terminazione del processo, cosa che viene eseguita nel ciclo in
+(\texttt{\small 15--21}).  Il ciclo è necessario a causa di una caratteristica
+fondamentale della gestione dei segnali: abbiamo già accennato come fra la
+generazione di un segnale e l'esecuzione del manipolatore possa passare un
+certo lasso di tempo; dato che questo lasso di tempo può dipendere da parecchi
+fattori esterni, niente ci assicura che il manipolatore venga eseguito prima
+della generazione di altri segnali dello stesso tipo. In questo caso
+normalmente i segnali vengono ``fusi'' insieme ed al processo ne viene
+recapitato soltanto uno.
+
+Questo può essere un caso comune proprio con \texttt{SIGCHLD}, quando molti
+processi figli terminano in rapida successione, e si presenta comunque tutte
+le volte che un segnale viene bloccato. Nel nostro caso se si chiamasse
+\func{waitpid} una sola volta si correrebbe il rischio di non leggere lo stato
+di uscita di tutti i processi effettivamente terminati, i cui segnali sono
+stati riuniti in uno solo. Per questo il ciclo di (\texttt{\small 15--21})
+ripete la lettura (eseguita con il parametro \macro{WNOHANG}, che permette di
+evitare il blocco della funzione) fintanto che essa non restitusce un valore
+nullo, segno che non resta nessun processo concluso di cui si debba ancora
+ricevere lo stato di terminazione.
 
 
 \section{Gestione avanzata}
@@ -1456,14 +1488,16 @@ risolvere i problemi pi
 \subsection{Un esempio di problema}
 \label{sec:sig_example}
 
-Come accennato in \ref{sec:sig_pause_sleep} è possibile implementare
+Come accennato in \secref{sec:sig_pause_sleep} è possibile implementare
 \func{sleep} a partire da dall'uso di \func{pause} e \func{alarm}. A prima
 vista questo può sembrare di implementazione immediata; ad esempio una
-semplice versione di \func{sleep} potrebbe essere la seguente:
+semplice versione di \func{sleep} potrebbe essere la seguente quella
+illustrata in \ref{fig:sig_sleep_wrong}.
+
 \begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{15cm}
-    \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+    \begin{lstlisting}{}
 unsigned int sleep(unsigned int seconds)
 {
     signandler_t prev_handler;
@@ -1491,7 +1525,7 @@ void alarm_hand(int sig) {
   \end{minipage} 
   \normalsize 
   \caption{Una implementazione sbagliata di \func{sleep}.} 
-  \label{fig:sig_timespec_def}
+  \label{fig:sig_sleep_wrong}
 \end{figure}
 
 Ma questa funzione, a parte il non gestire il caso in cui si è avuta una
index ca1fa7a98222e207f129532eb54e5b278b3f5974..b2a7b3c3975329c95643dc8925619dab8de8adbf 100644 (file)
@@ -1053,10 +1053,11 @@ Per riportare il tipo di errore il sistema usa la variabile globale
   può anche usare una macro, e questo è infatti il modo usato da Linux per
   renderla locale ai singoli thread.} definita nell'header \file{errno.h}; la
 variabile è in genere definita come \type{volatile} dato che può essere
-cambiata in modo asincrono da un segnale (per una descrizione dei segnali si
-veda \secref{cha:signals}), ma dato che un manipolatore di segnale scritto
-bene salva e ripristina il valore della variabile, di questo non è necessario
-preoccuparsi nella programmazione normale.
+cambiata in modo asincrono da un segnale (si veda \ref{sec:sig_sigchld} per un
+esempio, ricordando quanto trattato in \ref{sec:proc_race_cond}), ma dato che
+un manipolatore di segnale scritto bene salva e ripristina il valore della
+variabile, di questo non è necessario preoccuparsi nella programmazione
+normale.
 
 I valori che può assumere \var{errno} sono riportati in \capref{cha:errors},
 nell'header \file{errno.h} sono anche definiti i nomi simbolici per le