gestione.
+
\section{Introduzione}
\label{sec:sig_intro}
% 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
-vedremo in \ref{sec:sig_example}). In tal caso mescolare chiamata di
+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 \secref{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
implementazione completamente indipendente e questi problemi non ci sono.
\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{waitpid} 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 \secref{sec:sys_errno}) si
+comincia (\texttt{\small 12-13}) con il salvare lo stato corrente di
+\var{errno}, in modo da poterlo ripristinare prima del ritorno del
+manipolatore (\texttt{\small 22-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 e niente ci assicura che il manipolatore venga eseguito
+prima della generazione di ulteriori segnali dello stesso tipo. In questo caso
+normalmente i segnali segnali successivi vengono ``fusi'' col primo ed al
+processo ne viene recapitato soltanto uno.
+
+Questo può essere un caso comune proprio con \macro{SIGCHLD}, qualora capiti
+che molti processi figli terminino in rapida successione. Esso inoltre si
+presenta tutte le volte che un segnale viene bloccato: per quanti siano i
+segnali emessi durante il periodo di blocco, una volta che quest'ultimo sarà
+rimosso sarà 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 teminazione per un
+solo processo, anche se i processi terminati sono più di uno, e gli altri
+resterebbero in stato di 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
+ancora ricevere lo stato di terminazione (si veda \secref{sec:proc_wait} per
+la sintassi della funzione). Si noti anche come la funzione venga invocata con
+il parametro \macro{WNOHANG} che permette di evitare il suo blocco quando
+tutti gli stati di terminazione sono stati ricevuti.
Affronteremo queste problematiche in questa sezione, partendo da un esempio
che le evidenzi, per poi prendere in esame le varie funzioni che permettono di
-risolvere i problemi più complessi connessi alla programmazione con i segnali.
+risolvere i problemi più complessi connessi alla programmazione con i segnali,
+fino a trattare le caratteristiche generali della gestione dei medesimi nella
+casistica ordinaria.
\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 quella illustrata in
+\figref{fig:sig_sleep_wrong}.
+
+
+Dato che è nostra intenzione utilizzare \macro{SIGALARM} il primo passo della
+nostra implementazione di sarà quello di installare il relativo manipolatore
+salvando il precedente (\texttt{\small 4-7}). Si effettuerà poi una chiamata
+ad \func{alarm} per specificare il tempo d'attesa per l'invio del segnale a
+cui segue la chiamata a \func{pause} per fermare il programma (\texttt{\small
+ 8-9}) fino alla sua ricezione. Al ritorno di \func{pause}, causato dal
+ritorno del manipolatore (\texttt{\small 15-23}), si ripristina il
+manipolatore originario (\texttt{\small 10-11}) restituendo l'eventuale tempo
+rimanente (\texttt{\small 12-13}) che potrà essere diverso da zero qualora
+l'interruzione di \func{pause} venisse causata da un altro segnale.
+
\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{lstlisting}
\end{minipage}
\normalsize
- \caption{Una implementazione sbagliata di \func{sleep}.}
- \label{fig:sig_timespec_def}
+ \caption{Una implementazione pericolosa di \func{sleep}.}
+ \label{fig:sig_sleep_wrong}
\end{figure}
-Ma questa funzione, a parte il non gestire il caso in cui si è avuta una
-precedente chiamata a \func{alarm}, presenta una pericolosa race condition.
-Infatti se il processo viene interrotto fra la chiamata di \func{alarm} e
-\func{pause} può capitare (nel caso il sistema sia molto carico) che
-quest'ultima possa essere eseguita dopo l'arrivo di \macro{SIGALRM}. In questo
-caso ci si troverebbe di fronte ad un deadlock, in cui \func{pause} non
-verrebbe mai interrotta (se non in caso di 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à),
+presenta una pericolosa 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 quest'ultima, cosicchè essa sarebbe eseguita dopo l'arrivo di
+\macro{SIGALRM}. In questo caso ci si troverebbe di fronte ad un 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{longjump} (vedi \secref{sec:proc_longjmp}) per
+uscire dal manipolatore; in questo modo, con una condizione sullo stato di
+uscita di quest'ultima, si può evitare la chiamata a \func{pause}, usando un
+codice del tipo di quello riportato in \figref{fig:sig_sleep_incomplete}.
-Come abbiamo accennato in \secref{sec:proc_atom_oper} quando si ha a che fare
-con i segnali
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}{}
+static jmp_buff alarm_return;
+unsigned int sleep(unsigned int seconds)
+{
+ signandler_t prev_handler;
+ if ((prev_handler = signal(SIGALRM, alarm_hand)) == SIG_ERR) {
+ printf("Cannot set handler for alarm\n");
+ exit(1);
+ }
+ if (setjmp(alarm_return) == 0) { /* if not returning from handler */
+ alarm(second); /* call alarm */
+ pause(); /* then wait */
+ }
+ /* restore previous signal handler */
+ signal(SIGALRM, prev_handler);
+ /* remove alarm, return remaining time */
+ return alarm(0);
+}
+void alarm_hand(int sig) {
+ /* check if the signal is the right one */
+ if (sig != SIGALRM) { /* if not exit with error */
+ printf("Something wrong, handler for SIGALRM\n");
+ exit(1);
+ } else { /* return in main after the call to pause */
+ longjump(alarm_return, 1);
+ }
+}
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{Una implementazione ancora malfunzionante di \func{sleep}.}
+ \label{fig:sig_sleep_incomplete}
+\end{figure}
+In questo caso il manipolatore (\texttt{\small 18-26}) non ritorna come in
+\figref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 24}) per
+rientrare nel corpo principale del programma; dato che in questo caso il
+valore di uscita di \func{setjmp} è 1 grazie alla condizione in
+(\texttt{\small 9-12}) si evita comunque che \func{pause} sia chiamata a
+vuoto.
+
+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 in maniera più completa
projects / gapil.git / blobdiff