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