Finito con alarm e abort.
[gapil.git] / signal.tex
index 86a66b6c390b25c1f9cfd4df30f64fef423ea1eb..3bc1af18268fc02f28356d0a52e9988d0fd3d5f5 100644 (file)
@@ -45,8 +45,8 @@ il seguente:
 \item una richiesta dell'utente di terminare o fermare il programma. In genere
   si realizza attraverso un segnale mandato dalla shell in corrispondenza
   della pressione di tasti del terminale come \code{C-c} o
 \item una richiesta dell'utente di terminare o fermare il programma. In genere
   si realizza attraverso un segnale mandato dalla shell in corrispondenza
   della pressione di tasti del terminale come \code{C-c} o
-  \code{C-z}\footnote{indichiamo con \code{C-x} la pressione simultanea al
-    tasto \code{x} del tasto control (ctrl in molte tastiere)}.
+  \code{C-z}.\footnote{indichiamo con \code{C-x} la pressione simultanea al
+    tasto \code{x} del tasto control (ctrl in molte tastiere).}
 \item l'esecuzione di una \func{kill} o di una \func{raise} da parte del
   processo stesso o di un'altro (solo nel caso della \func{kill}).
 \end{itemize*}
 \item l'esecuzione di una \func{kill} o di una \func{raise} da parte del
   processo stesso o di un'altro (solo nel caso della \func{kill}).
 \end{itemize*}
@@ -73,7 +73,7 @@ semantiche) che vengono chiamate rispettivamente semantica \textsl{affidabile}
 \textit{unreliable}).
 
 Nella semantica \textsl{inaffidabile} (quella implementata dalle prime
 \textit{unreliable}).
 
 Nella semantica \textsl{inaffidabile} (quella implementata dalle prime
-versioni di unix) la routine di gestione del segnale specificata dall'utente
+versioni di Unix) la routine di gestione del segnale specificata dall'utente
 non resta attiva una volta che è stata eseguita; è perciò compito dell'utente
 stesso ripetere l'installazione della stessa all'interno della routine di
 gestione, in tutti i casi in cui si vuole che il manipolatore esterno resti
 non resta attiva una volta che è stata eseguita; è perciò compito dell'utente
 stesso ripetere l'installazione della stessa all'interno della routine di
 gestione, in tutti i casi in cui si vuole che il manipolatore esterno resti
@@ -260,31 +260,29 @@ ignorato, non sar
 è specificata una azione diversa (nel qual caso solo i segnali successivi alla
 nuova specificazione saranno notificati).
 
 è specificata una azione diversa (nel qual caso solo i segnali successivi alla
 nuova specificazione saranno notificati).
 
-Una volta che il segnale viene notificato (che questo avvenga subito o dopo
-una attesa più o meno lunga) viene eseguita l'azione specificata per detto
+Una volta che un segnale viene notificato (che questo avvenga subito o dopo
+una attesa più o meno lunga) viene eseguita l'azione specificata per il
 segnale. Per alcuni segnali (\macro{SIGKILL} e \macro{SIGSTOP}) questa azione
 segnale. Per alcuni segnali (\macro{SIGKILL} e \macro{SIGSTOP}) questa azione
-è fissa e non può essere cambiata, ma per tutti gli altri si può specificare
-una scelta fra le tre seguenti:
+è fissa e non può essere cambiata, ma per tutti gli altri si può selezionare
+una  delle tre possibilità seguenti:
 
 \begin{itemize*}
 
 \begin{itemize*}
-\item \textsl{ignorare} il segnale.
-\item \textsl{catturare} il segnale, ed utilizzare il manipolatore
-  specificato.
+\item ignorare il segnale.
+\item catturare il segnale, ed utilizzare il manipolatore specificato.
 \item accettare l'azione di default per quel segnale.
 \end{itemize*}
 
 \item accettare l'azione di default per quel segnale.
 \end{itemize*}
 
-Un programma può specificare queste scelte usano le due funzioni \func{signal}
-e \func{sigaction} (vedi \secref{sec:sig_signal} e ); se si è installato un
-manipolatore sarà quest'ultimo ad essere eseguito alla notifica del segnale.
-Inoltre il sistema fa si che mentre viene eseguito il manipolatore di un
-segnale, questo ultimo venga automaticamente bloccato (così si possono evitare
-race condition).
+Un programma può specificare queste scelte usando le due funzioni
+\func{signal} e \func{sigaction} (vedi \secref{sec:sig_signal} e
+\secref{sec:sig_sigaction}); se si è installato un manipolatore sarà
+quest'ultimo ad essere eseguito alla notifica del segnale.  Inoltre il sistema
+fa si che mentre viene eseguito il manipolatore di un segnale, questo ultimo
+venga automaticamente bloccato (così si possono evitare race condition).
 
 
-Se arriva un segnale per il quale non è stato specificata un'azione viene
-utilizzata l'azione standard. Questa è diversa da segnale a segnale (come
-vedremo in \secref{sec:sig_standard}); nella maggior parte dei casi essa
-comporta la terminazione del processo, per alcuni segnali che rappresentano
-eventi innocui invece l'azione di default è quella di essere ignorati.
+Nel caso non sia stata specificata un'azione, viene utilizzata l'azione
+standard che (come vedremo in \secref{sec:sig_standard}) è propria di ciascun
+segnale; nella maggior parte dei casi essa porta alla terminazione del
+processo, ma alcuni segnali che rappresentano eventi innocui vengono ignorati.
 
 Quando un segnale termina un processo, il padre può determinare la causa della
 terminazione esaminando il codice di stato riportato delle funzioni
 
 Quando un segnale termina un processo, il padre può determinare la causa della
 terminazione esaminando il codice di stato riportato delle funzioni
@@ -294,18 +292,19 @@ 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 prima della
-terminazione, che e può essere esaminato da un debugger per investigare sulla
-causa dell'errore.  Lo stesso avviene se i suddetti segnale vengono generati
-con una \func{kill}.
+\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 segnale vengono generati con una \func{kill}.
+
 
 
 \section{La classificazione dei segnali}
 \label{sec:sig_classification}
 
 
 
 \section{La classificazione dei segnali}
 \label{sec:sig_classification}
 
-Esamineremo in questa sezione i vari segnali definiti nel sistema, le loro
-caratteristiche e tipologia, le varie macro e costanti che permettono di
-identificarli, e le funzioni che ne stampano la descrizione.
+Esamineremo in questa sezione quali sono i vari segnali definiti nel sistema,
+le loro caratteristiche e tipologia, le varie macro e costanti che permettono
+di identificarli, e le funzioni che ne stampano la descrizione.
 
 
 \subsection{I segnali standard}
 
 
 \subsection{I segnali standard}
@@ -313,7 +312,8 @@ identificarli, e le funzioni che ne stampano la descrizione.
 
 Ciascun segnale è identificato rispetto al sistema da un numero, ma l'uso
 diretto di questo numero da parte dei programmi è da evitare, in quanto esso
 
 Ciascun segnale è identificato rispetto al sistema da un numero, ma l'uso
 diretto di questo numero da parte dei programmi è da evitare, in quanto esso
-può variare a seconda dell'implementazione del sistema. 
+può variare a seconda dell'implementazione del sistema, e nel caso si Linux,
+anche a seconda dell'architettura hardware. 
 
 \begin{table}[htb]
   \footnotesize
 
 \begin{table}[htb]
   \footnotesize
@@ -323,56 +323,56 @@ pu
     \textbf{Segnale}&\textbf{Standard}&\textbf{Azione}&\textbf{Descrizione} \\
     \hline
     \hline
     \textbf{Segnale}&\textbf{Standard}&\textbf{Azione}&\textbf{Descrizione} \\
     \hline
     \hline
-    \macro{SIGHUP}   &PL& A &Hangup o fine del processo di controllo\\
-    \macro{SIGINT}   &PL& A &Interrupt da tastiera (\cmd{C-c})\\
-    \macro{SIGQUIT}  &PL& C &Quit da tastiera (\cmd{C-y}) \\
-    \macro{SIGILL}   &PL& C & Istruzione illegale\\
-    \macro{SIGABRT}  &PL& C & Segnale di abort da \func{abort} \\
-    \macro{SIGFPE}   &PL& C & Errore aritmetico\\
-    \macro{SIGKILL}  &PL&AEF& Segnale di terminazione forzata \\
-    \macro{SIGSEGV}  &PL& C & Errore di accesso in memoria\\
-    \macro{SIGPIPE}  &PL& A & Pipe spezzata\\
-    \macro{SIGALRM}  &PL& A & Segnale del timer da \func{alarm} \\
-    \macro{SIGTERM}  &PL& A & Segnale di terminazione \verb|C-\|\\
-    \macro{SIGUSR1}  &PL& A & Segnale utente numero 1\\
-    \macro{SIGUSR2}  &PL& A & Segnale utente numero 2\\
-    \macro{SIGCHLD}  &PL& B & Figlio terminato o fermato\\
-    \macro{SIGCONT}  &PL&   & Continua se fermato\\
-    \macro{SIGSTOP}  &PL&DEF& Ferma il processo\\
-    \macro{SIGTSTP}  &PL& D & Stop typed at tty \\
-    \macro{SIGTTIN}  &PL& D & Input sul terminale per un processo 
-                              in background\\
-    \macro{SIGTTOU}  &PL& D & Output sul terminale per un processo 
-                              in background\\
-    \macro{SIGBUS}   &SL& C & Errore sul bus (bad memory access) \\
-    \macro{SIGPOLL}  &SL& A & Pollable event (Sys V). 
-                              Sinonimo di \macro{SIGIO}\\
-    \macro{SIGPROF}  &SL& A & Timer del profiling scaduto \\
-    \macro{SIGSYS}   &SL& C & Bad argument to routine (SVID)\\
-    \macro{SIGTRAP}  &SL & C & Trace/breakpoint trap \\
-    \macro{SIGURG}   &SLB& B & Urgent condition on socket\\
-    \macro{SIGVTALRM}&SLB& A & Virtual alarm clock\\
-    \macro{SIGXCPU}  &SLB& C & Ecceduto il limite sul CPU time\\
-    \macro{SIGXFSZ}  &SLB& C & Ecceduto il limite sulla dimezsione dei file\\
-    \macro{SIGIOT}   &L & C & IOT trap. A synonym for SIGABRT        \\
-    \macro{SIGEMT}   &L &   &                                        \\
-    \macro{SIGSTKFLT}&L & A & Stack fault on coprocessor             \\
-    \macro{SIGIO}    &LB& A & I/O now possible (4.2 BSD)             \\
-    \macro{SIGCLD}   &L &   & A synonym for SIGCHLD                  \\
-    \macro{SIGPWR}   &L & A & Power failure (System V)               \\
-    \macro{SIGINFO}  &L &   & A synonym for SIGPWR                   \\
-    \macro{SIGLOST}  &L & A & File lock lost                         \\
-    \macro{SIGWINCH} &LB& B & Window resize signal (4.3 BSD, Sun)    \\
-    \macro{SIGUNUSED}&L & A & Unused signal (will be SIGSYS)         \\
+    \macro{SIGHUP}   &PL & A & Hangup o fine del processo di controllo      \\
+    \macro{SIGINT}   &PL & A & Interrupt da tastiera (\cmd{C-c})            \\
+    \macro{SIGQUIT}  &PL & C & Quit da tastiera (\cmd{C-y})                 \\
+    \macro{SIGILL}   &PL & C & Istruzione illegale                          \\
+    \macro{SIGABRT}  &PL & C & Segnale di abort da \func{abort}             \\
+    \macro{SIGFPE}   &PL & C & Errore aritmetico                            \\
+    \macro{SIGKILL}  &PL &AEF& Segnale di terminazione forzata              \\
+    \macro{SIGSEGV}  &PL & C & Errore di accesso in memoria                 \\
+    \macro{SIGPIPE}  &PL & A & Pipe spezzata                                \\
+    \macro{SIGALRM}  &PL & A & Segnale del timer da \func{alarm}             \\
+    \macro{SIGTERM}  &PL & A & Segnale di terminazione \verb|C-\|            \\
+    \macro{SIGUSR1}  &PL & A & Segnale utente numero 1                       \\
+    \macro{SIGUSR2}  &PL & A & Segnale utente numero 2                       \\
+    \macro{SIGCHLD}  &PL & B & Figlio terminato o fermato                    \\
+    \macro{SIGCONT}  &PL &   & Continua se fermato                           \\
+    \macro{SIGSTOP}  &PL &DEF& Ferma il processo                             \\
+    \macro{SIGTSTP}  &PL & D & Stop typed at tty                             \\
+    \macro{SIGTTIN}  &PL & D & Input sul terminale per un processo 
+                               in background                                 \\
+    \macro{SIGTTOU}  &PL & D & Output sul terminale per un processo          
+                               in background                                 \\
+    \macro{SIGBUS}   &SL & C & Errore sul bus (bad memory access)            \\
+    \macro{SIGPOLL}  &SL & A & Pollable event (Sys V).                      
+                               Sinonimo di \macro{SIGIO}                     \\
+    \macro{SIGPROF}  &SL & A & Timer del profiling scaduto                   \\
+    \macro{SIGSYS}   &SL & C & Bad argument to routine (SVID)                \\
+    \macro{SIGTRAP}  &SL & C & Trace/breakpoint trap                         \\
+    \macro{SIGURG}   &SLB& B & Urgent condition on socket                    \\
+    \macro{SIGVTALRM}&SLB& A & Virtual alarm clock                           \\
+    \macro{SIGXCPU}  &SLB& C & Ecceduto il limite sul CPU time               \\
+    \macro{SIGXFSZ}  &SLB& C & Ecceduto il limite sulla dimensione dei file  \\
+    \macro{SIGIOT}   &L  & C & IOT trap. A synonym for \macro{SIGABRT}       \\
+    \macro{SIGEMT}   &L  &   &                                               \\
+    \macro{SIGSTKFLT}&L  & A & Stack fault on coprocessor                    \\
+    \macro{SIGIO}    &LB & A & I/O now possible (4.2 BSD)                    \\
+    \macro{SIGCLD}   &L  &   & A synonym for \macro{SIGCHLD}                 \\
+    \macro{SIGPWR}   &L  & A & Fallimento dell'alimentazione                 \\
+    \macro{SIGINFO}  &L  &   & A synonym for \macro{SIGPWR}                  \\
+    \macro{SIGLOST}  &L  & A & Perso un lock sul file (per NFS)              \\
+    \macro{SIGWINCH} &LB & B & Window resize signal (4.3 BSD, Sun)           \\
+    \macro{SIGUNUSED}&L  & A & Unused signal (will be SIGSYS)                \\
     \hline
   \end{tabular}
   \caption{Lista dei segnali in Linux.}
   \label{tab:sig_signal_list}
 \end{table}
 
     \hline
   \end{tabular}
   \caption{Lista dei segnali in Linux.}
   \label{tab:sig_signal_list}
 \end{table}
 
-Per questo motivo ad ogni segnale viene associato un nome, che corrisponde,
-tramite una macro di preprocessore, al suddetto numero. Sono questi nomi, che
-sono standardizzati e sostanzialemnte uniformi rispetto alle varie
+Per questo motivo ad ogni segnale viene associato un nome, definendo con una
+macro di preprocessore una costante uguale al suddetto numero. Sono questi
+nomi, che sono standardizzati e sostanzialemnte uniformi rispetto alle varie
 implementazioni, che si devono usare nei programmi. Tutti i nomi e le funzioni
 che concernono i segnali sono definiti nell'header di sistema \file{signal.h}.
 
 implementazioni, che si devono usare nei programmi. Tutti i nomi e le funzioni
 che concernono i segnali sono definiti nell'header di sistema \file{signal.h}.
 
@@ -428,8 +428,8 @@ stato dello stack e delle variabili al momento della ricezione del segnale.
     \hline
     P & POSIX. \\
     B & BSD. \\
     \hline
     P & POSIX. \\
     B & BSD. \\
-    L & Linux \\
-    S & SUSv2 \\
+    L & Linux.\\
+    S & SUSv2.\\
     \hline
   \end{tabular}
   \caption{Legenda dei valori della colonna \textbf{Standard} di 
     \hline
   \end{tabular}
   \caption{Legenda dei valori della colonna \textbf{Standard} di 
@@ -750,87 +750,530 @@ descritta in \secref{sec:sys_strerror}; il suo prototipo 
 
 Una modalità alternativa per utilizzare le descrizioni restituite da
 \func{strsignal} e \func{psignal} è quello di fare usare la variabile
 
 Una modalità alternativa per utilizzare le descrizioni restituite da
 \func{strsignal} e \func{psignal} è quello di fare usare la variabile
-\var{sys\_siglist}, che può essere acceduta dichiarando:
+\var{sys\_siglist}, che è definita in \file{signal.h} e può essere acceduta
+con la dichiarazione:
 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
     extern const char *const sys_siglist[]
 \end{lstlisting}
 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
     extern const char *const sys_siglist[]
 \end{lstlisting}
-\var{sys\_siglist} contiene le stringhe di descrizione indicizzate per numero
-di segnale, per cui \code{char *decr = strsignal(SIGINT)} può essere
-sostituito dall'equivalente \code{char *decr = sys\_siglist[SIGINT]}.
+l'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
+indicizzate per numero di segnale, per cui una chiamata del tipo di \code{char
+  *decr = strsignal(SIGINT)} può essere sostituita dall'equivalente \code{char
+  *decr = sys\_siglist[SIGINT]}.
 
 
 
 \section{La gestione dei segnali}
 
 
 
 \section{La gestione dei segnali}
-\label{sec:sig_handlers}
+\label{sec:sig_management}
+
+I segnali sono il primo e più classico esempio di eventi asincroni, cioè di
+eventi che possono accadere in un qualunque momento durante l'esecuzione di un
+programma. Per questa loro caratteristica la loro gestione non può essere
+effettuata all'interno del normale flusso di esecuzione dello stesso, ma è
+delegata appunto agli eventuali manipolatori che si sono installati.
+
+In questa sezione vedremo come si effettua gestione dei segnali, a partire
+dalla loro interazione con le system call, passando per le varie funzioni che
+permettono di installare i manipolatori e controllare le reazioni di un
+processo alla loro occorrenza.
+
+
+\subsection{Il comportamento generale del sistema.}
+\label{sec:sig_gen_beha}
+
+Abbiamo già trattato in \secref{sec:sig_intro} le modalità con cui il sistema
+gestisce l'interazione fra segnali e processi, ci resta da esaminare però il
+comportamento delle system call; in particolare due di esse, \func{fork} ed
+\func{exec}, dovranno essere prese esplicitamente in considerazione, data la
+loro stretta relazione con la creazione di nuovi processi.
+
+Come accennato in \secref{sec:proc_fork} quando viene creato un nuovo processo
+con \func{fork} esso eredita dal padre sia le azioni che sono state settate
+per i singoli segnali, che la maschera dei segnali bloccati (tratteremo
+quest'ultimo argomento in \ref{sec:sig_sigpending}). Invece tutti i segnali
+pendenti e gli allarmi vengono cancellati; essi infatti devono essere
+recapitati solo al padre, al figlio dovranno arrivare solo i segnali dovuti
+alle sue azioni.
+
+Quando si mette in esecuzione un nuovo programma con \func{exec} (si ricordi
+quanto detto in \secref{sec:prog_exec}) tutti i segnali per i quali è stato
+installato un manipolatore vengono resettati a \macro{SIG\_DFL}. Non ha più
+senso infatti fare riferimento a funzioni definite nel programma originario,
+che non sono nemmeno presenti nello spazio di indirizzi del nuovo programma.
+
+Si noti che questo vale solo per le azioni per le quali è stato installato un
+manipolatore; viene mantenuto invece ogni eventuale settaggio dell'azione a
+\macro{SIG\_IGN}. Questo permette ad esempio alla shell di settare ad
+\macro{SIG\_IGN} le risposte per \macro{SIGINT} e \macro{SIGQUIT} per i
+programmi eseguiti in background, che altrimenti sarebbero interrotti da una
+successiva pressione di \texttt{C-c} o \texttt{C-y}.
+
+Per quanto riguarda tutte le altre system call esse vengono tradizionalmente
+classificate, proprio in base al loro comportamento nei confronti dei segnali,
+in \textsl{lente} (\textit{slow}) e \textsl{veloci} (\textit{fast}). La gran
+parte appartiene a quest'ultima categoria che non è influenzata dall'arrivo di
+un segnale. In tal caso un eventuale manipolatore viene sempre eseguito dopo
+che la system call è stata completata. Esse sono dette \textsl{veloci} proprio
+in quanto la loro esecuzione è sostanzialmente immediata e attendere per
+eseguire un manipolatore non comporta nessun inconveniente.
+
+Esistono però dei casi in cui questo non è possibile perché renderebbe
+impossibile una risposta pronta al segnale. In generale questo avviene tutte
+le volte che si ha a che fare con system call che possono bloccarsi
+indenfinitamente, che per questo vengono chiamate \textsl{lente}. Un elenco
+dei casi in cui si presenta questa situazione è il seguente:
+\begin{itemize*}
+\item lettura da file che possono bloccarsi in attesa di dati non ancora
+  presenti (come per certi file di dispositivo, la rete o le pipe).
+\item scrittura sugli stessi file, nel caso in cui dati non possano essere
+  accettati immediatamente.
+\item apertura di un file di dipositivo che richiede operazioni non immediate
+  per una una risposta. 
+\item operazioni eseguite con \func{ioctl} che non è detto possano essere
+  eseguite immediatamente.
+\item le funzioni di intercomunicazione che si bloccano in attesa di risposte
+  da altri processi.
+\item la funzione \func{pause} (usata appunto per attendere l'arrivo di un
+  segnale).
+\item la funzione \func{wait} (se nessun processo figlio è ancora terminato).
+\end{itemize*}
+
+In questo caso si pone il problema di cosa fare una volta che il manipolatore
+sia ritornato. La scelta originaria dei primi Unix era quella di far ritornare
+anche la system call restituendo l'errore di \macro{EINTR}. Questa è a
+tutt'oggi una scelta corrente, ma comporta che i programmi che usano dei
+manipolatori controllino lo stato di uscita delle funzioni per ripeterne la
+chiamata qualora l'errore fosse questo.
 
 
-I segnali sono il primo e più classico esempio di eventi asincroni, che
-possono accadere in un qualunque momento durante l'esecuzione di un programma.
-Non essendo sotto il controllo del programma la gestione dei segnali non potrà
-essere controllata all'interno del flusso di esecuzione di quest'ultimo, ma
-tutto quello che si potrà fare è di specificare (al kernel, che li genera)
-quale azione andrà intrapresa quando essi si verificano.
+Dimenticarsi di richiamare una system call interrotta da un segnale è un
+errore comune, tanto che le \acr{glibc} provvedono una macro
+\code{TEMP\_FAILURE\_RETRY(expr)} che esegue l'operazione automaticamente,
+ripetendo l'esecuzione dell'espressione \var{expr} fintanto che il risultato
+non è diverso dall'uscita con un errore \macro{EINTR}.
 
 
-In questa sezione vedremo allora come si gestiscono i segnali, esaminando le
-funzioni che si usano per effettuare la gestione dei segnali ed analizzando le
-problematiche relative alla gestione di eventi asincroni di questo tipo.
+La soluzione è comunque poco elegante e BSD ha scelto un approccio molto
+diverso, che è quello di fare ripartire automaticamente la system call invece
+di farla fallire. In questo caso ovviamente non c'è da preoccuparsi di
+controllare il codice di errore; si perde però la possibilità di eseguire
+azioni specifiche all'occorrenza di questa particolare condizione. 
+
+Linux e le \acr{glibc} consentono di utilizzare entrambi gli approcci,
+attraverso una opportuna opzione di \func{sigaction} (vedi
+\secref{sec:sig_sigaction}). È da chiarire comunque che nel caso di
+interruzione nel mezzo di un trasferimento parziale di dati, le system call
+ritornano sempre indicando i byte trasferiti.
 
 
 \subsection{La funzione \func{signal}}
 \label{sec:sig_signal}
 
 
 
 \subsection{La funzione \func{signal}}
 \label{sec:sig_signal}
 
-L'interfaccia più semplice alla manipolazione dei segnali è costituita dalla
-funzione \func{signal}; questa funzione è definita fin dallo standard ANSI C
-che però non considera sistemi multitasking, per cui la sua definizione in
-tale standard è tanto vaga da essere del tutto inutile in un sistema unix, per
-questo ogni implementazione successiva ne ha modificato e ridefinito il
+L'interfaccia più semplice per la gestione dei segnali è costituita dalla
+funzione \func{signal} che è definita fin dallo standard ANSI C.  Quest'ultimo
+però non considera sistemi multitasking, per cui la definizione è tanto vaga
+da essere del tutto inutile in un sistema Unix; è questo il motivo per cui
+ogni implementazione successiva ne ha modificato e ridefinito il
 comportamento, pur mantenendone immutato il prototipo\footnote{in realtà
   alcune vecchie implementazioni (SVR4 e 4.3+BSD) usano parametri aggiuntivi
 comportamento, pur mantenendone immutato il prototipo\footnote{in realtà
   alcune vecchie implementazioni (SVR4 e 4.3+BSD) usano parametri aggiuntivi
-  per definire il comportamento della funzione} che è:
+  per definire il comportamento della funzione.} che è:
 \begin{prototype}{signal.h}
   {sighandler\_t signal(int signum, sighandler\_t handler)} 
   
 \begin{prototype}{signal.h}
   {sighandler\_t signal(int signum, sighandler\_t handler)} 
   
-  Installa una nuova funzione di gestione (manipolatore) per il segnale
-  \param{signum}, usando il manipolatore \param{handler}.
+  Installa la funzione di gestione \param{handler} (il manipolatore) per il
+  segnale \param{signum}.
   
   \bodydesc{La funzione ritorna il precedente manipolatore in caso di successo
     o \macro{SIG\_ERR} in caso di errore.}
 \end{prototype}
 
 In questa definizione si è usato il tipo \type{sighandler\_t} che è una
   
   \bodydesc{La funzione ritorna il precedente manipolatore in caso di successo
     o \macro{SIG\_ERR} in caso di errore.}
 \end{prototype}
 
 In questa definizione si è usato il tipo \type{sighandler\_t} che è una
-estensione GNU definita in Linux che permette di riscrivere il prototipo in
-forma più leggibile dell'originario \code{void (*signal(int signum, void
-  (*handler)(int)))int)}, e che è sostanzialmente equivalente alla
-definizione:
+estensione GNU, definita dalle \acr{glibc}, che permette di riscrivere il
+prototipo in una forma più leggibile dell'originario:
+\begin{verbatim}
+void (*signal(int signum, void (*handler)(int)))int)
+\end{verbatim}
+questa infatti, per la poca chiarezza della sintassi del C quando si vanno a
+trattare puntatori a funzioni, è molto meno comprensibile.  Da un confronto
+con il precedente prototipo si può dedurre la definizione di
+\type{sighandler\_t} che è:
 \begin{verbatim}
     typedef void (* sighandler_t)(int) 
 \end{verbatim}
 \begin{verbatim}
     typedef void (* sighandler_t)(int) 
 \end{verbatim}
-cioè un puntatore ad una funzione di tipo \type{void} con un parametro di tipo
-\type{int}\footnote{si devono usare le parentesi intorno al nome della
-  funzione per via delle precedenze degli operatori del C, senza di esse si
-  sarebbe definita una funzione che ritorna un puntatore a \type{void} e non
-  un puntatore ad una funzione \type{void}}.
-
-Il numero di segnale passato in \param{signum} segnale può essere indicato
-direttamente con una delle costanti definite in \secref{sec:sig_standard}, il
+e cioè un puntatore ad una funzione \type{void} (cioè senza valore di ritorno)
+e che prende un argomento di tipo \type{int}.\footnote{si devono usare le
+  parentesi intorno al nome della funzione per via delle precedenze degli
+  operatori del C, senza di esse si sarebbe definita una funzione che ritorna
+  un puntatore a \type{void} e non un puntatore ad una funzione \type{void}.}
+La funzione \func{signal} quindi restituisce e prende come secondo argomento
+un puntatore a una funzione di questo tipo, che è appunto il manipolatore del
+segnale.
+
+Il numero di segnale passato in \param{signum} può essere indicato
+direttamente con una delle costanti definite in \secref{sec:sig_standard}. Il
 manipolatore \param{handler} invece, oltre all'indirizzo della funzione da
 manipolatore \param{handler} invece, oltre all'indirizzo della funzione da
-chiamare all'occorrenza del segnale, può assumere anche i valori costanti
+chiamare all'occorrenza del segnale, può assumere anche i due valori costanti
 \macro{SIG\_IGN} con cui si dice ignorare il segnale e \macro{SIG\_DFL} per
 \macro{SIG\_IGN} con cui si dice ignorare il segnale e \macro{SIG\_DFL} per
-installare l'azione di di default (si ricordi però che i due segnali
-\macro{SIGKILL} e \macro{SIGSTOP} non possono essere ignorati né
-intercettati).
+installare l'azione di di default.\footnote{si ricordi però che i due segnali
+  \macro{SIGKILL} e \macro{SIGSTOP} non possono essere ignorati né
+  intercettati.}
+
+La funzione restituisce l'indirizzo dell'azione precedente, che può essere
+salvato per poterlo ripristinare (con un'altra chiamata a \func{signal}) in un
+secondo tempo. Si ricordi che se si setta come azione \macro{SIG\_IGN} (o si
+setta un \macro{SIG\_DFL} per un segnale il cui default è di essere ignorato),
+tutti i segnali pendenti saranno scartati, e non verranno mai notificati.
+
+L'uso di \func{signal} è soggetto a problemi di compatibilità, dato che essa
+si comporta in maniera diversa per sistemi derivati da BSD o da System V. In
+questi ultimi infatti la funzione è conforme al comportamento originale dei
+primi Unix in cui il manipolatore viene disinstallato alla sua chiamata
+secondo la semantica inaffidabile; Linux seguiva questa convenzione fino alle
+\acr{libc5}. Al contrario BSD segue la semantica affidabile, non resettando il
+manipolatore e bloccando il segnale durante l'esecuzione dello stesso. Con
+l'utilizzo delle \acr{glibc2} anche Linux è passato a questo comportamento;
+quello della versione originale della funzione, il cui uso è deprecato per i
+motivi visti in \secref{sec:sig_semantics}, può essere ottenuto chiamando
+\func{sysv\_signal}.  In generale, per evitare questi problemi, tutti i nuovi
+programmi dovrebbero usare \func{sigaction}.
+
+È da tenere presente che, seguendo lo standard POSIX, il comportamento di un
+processo che ignora i segnali \macro{SIGFPE}, \macro{SIGILL}, o
+\macro{SIGSEGV} (qualora non originino da una \func{kill} o una \func{raise})
+è indefinito. Un manipolatore che ritorna da questi segnali può dare luogo ad
+un ciclo infinito.
+
+
+\subsection{Le funzioni \func{kill} e \func{raise}}
+\label{sec:sig_kill_raise}
+
+Come accennato in \secref{sec:sig_types}, un segnale può essere generato
+direttamente da un processo. L'invio di un sengale generico può essere
+effettuato attraverso delle funzioni \func{kill} e \func{raise}. La prima
+serve per inviare un segnale al processo corrente, ed il suo prototipo è:
+\begin{prototype}{signal.h}{int raise(int sig)}
+  Invia il segnale \param{sig} al processo corrente.
+  
+  \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
+    errore, il solo errore restituito è \macro{EINVAL} qualora si sia
+    specificato un numero di segnale invalido.}
+\end{prototype}
+
+Il valore di \param{sig} specifica il segnale che si vuole inviare e può
+essere specificato con una delle macro definite in
+\secref{sec:sig_classification}.  In genere questa funzione viene usata per
+riprodurre il comportamento di default di un segnale che sia stato
+intercettato. In questo caso, una volta eseguite le operazioni volute, il
+manipolatore potrà reinstallare l'azione di default, e attivarla con
+\func{raise}.
+
+Se invece si vuole inviare un segnale ad un altro processo occorre utilizzare
+la funzione \func{kill}; il suo prototipo è:
+\begin{functions}
+  \headdecl{sys/types.h}
+  \headdecl{signal.h}
+  \funcdecl{int kill(pid\_t pid, int sig)} Invia il segnale \param{sig} al
+  processo specificato con \param{pid}.
+
+  \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
+    errore, nel qual caso \var{errno} assumerà i valori:
+  \begin{errlist}
+  \item[\macro{EINVAL}] Si è specificato un numero di segnale invalido.
+  \item[\macro{EPERM}] Il processo non ha il permesso di inviare il segnale
+  alla destinazione specificata.
+  \item[\macro{ESRCH}] Il \acr{pid} o il process group indicati non
+  esistono. Gli zombie (vedi \ref{sec:proc_termination}) sono considerati come
+  processi esistenti.
+  \end{errlist}}
+\end{functions}
+
+La funzione \code{raise(sig)} è sostanzialmente equivalente ad una
+\code{kill(getpid(), sig)}. Siccome \func{raise} è definita nello standard ISO
+C non esiste in alcune vecchie versioni di Unix, per cui in generale l'uso di
+\func{kill} è più portabile.
+
+Lo standard POSIX poi prevede che il valore 0 sia usato per specificare il
+segnale nullo.  Se le funzioni vengono chiamate con questo valore non viene
+inviato nessun segnale, ma viene eseguito il controllo degli errori, in tal
+caso si otterrà un errore \macro{EPERM} se non si hanno i permessi necessari
+ed un errore \macro{ESRCH} se il processo specificato non esiste. Si tenga
+conto però che il sistema ricicla i \acr{pid} (come accennato in
+\secref{sec:proc_pid}) per cui l'esistenza di un processo non significa che
+esso sia realmente quello a cui si intendeva mandare il segnale.
+
+Il valore dell'argomento \param{pid} specifica la destinazione a cui inviare
+il segnale e può assumere i seguenti significati:
+\begin{basedescript}{\desclabelwidth{2cm}\desclabelstyle{\nextlinelabel}}
+\item[$\texttt{pid}>0$] il segnale è mandato al processo con il \acr{pid}
+  indicato.
+\item[$\texttt{pid}=0$] il segnale è mandato ad ogni processo del
+  \textit{process group} del chiamante.
+\item[$\texttt{pid}=-1$] il segnale è mandato ad ogni processo (eccetto
+  \cmd{init}).
+\item[$\texttt{pid}<-1$] il segnale è mandato ad ogni processo del process
+  group $|\code{pid}|$.
+\end{basedescript}
+
+Solo l'amministratore può inviare un segnale ad un processo qualunque, in
+tutti gli altri casi il \textit{real user id} o l'\textit{effective user id}
+del processo chiamante devono corrispondere al \textit{real user id} o al
+\textit{saved user id} della destinazione. Fa eccezione il caso in cui il
+segnale inviato sia \macro{SIGCONT}, nel quale occorre che entrambi i processi
+appartengano alla stessa sessione. Inoltre, dato il ruolo fondamentale che
+riveste nel sistema (si ricordi quanto visto in \secref{sec:sig_termination}),
+non è possibile inviare al processo 1 (cioè a \cmd{init}) segnali per i quali
+esso non abbia un manipolatore installato.
+
+Infine, seguendo le specifiche POSIX 1003.1-2001, l'uso della chiamata
+\code{kill(-1, sig)} comporta che il segnale sia inviato (con la solita
+eccezione di \cmd{init}) a tutti i processi per i quali i permessi lo
+consentano. Lo standard permette comunque alle varie implementazione di
+escludere alcuni processi specifici: nel caso in questione Linux non invia il
+segnale al processo che ha effettuato la chiamata.
+
+
+\subsection{Le funzioni \func{alarm} e \func{abort}}
+\label{sec:sig_alarm_abort}
+
+Un caso particolare di segnali generati a richiesta è quello che riguarda i
+segnali di temporizzazione e e \macro{SIGABORT}, per i quali sono previste
+funzioni specifiche che ne effettuino l'invio. La prima di queste è
+\func{alarm} il cui prototipo è:
+\begin{prototype}{unistd.h}{unsigned int alarm(unsigned int seconds)}
+  Predispone l'invio di \macro{SIGALARM} dopo \param{seconds} secondi.
+  
+  \bodydesc{La funzione restituisce il numero di secondi rimanenti ad un
+    precedente allarme, o zero se non c'erano allarmi pendenti.}
+\end{prototype}
+
+La funzione provvede un meccanismo che consente ad un processo di predisporre
+un'interruzione nel futuro, (ad esempio per effettuare una qualche operazione
+dopo un certo periodo di tempo), programmando l'emissione si un segnale di
+\macro{SIGALARM} dopo il numero di secondi specificato da \param{seconds}.
+
+Se si specifica per \param{seconds} un valore nullo non verrà inviato nessun
+segnale; siccome alla chiamata viene cancellato ogni precedente allarme,
+questo può essere usato per cancellare una programmazione precedente. La
+funzione inoltre ritorna il numero di secondi rimanenti all'invio dell'allarme
+precedentemente programmato, in modo che sia eventualmente possibile
+effettuare delle scelte in caso di necessità di più interruzioni.
+
+In \secref{sec:sys_unix_time} abbiamo visto che ad ogni processo sono
+associati tre tempi diversi: \textit{clock time}, \textit{user time} e
+\textit{system time}.  Per poterli calcolare il kernel mantiene tre diversi
+timer per ciascun processo:
+\begin{itemize}
+\item un \textit{real-time timer} che calcola il tempo reale trascorso (che
+  corrisponde al \textit{clock time}). La scadenza di questo timer provoca
+  l'emissione di \macro{SIGALARM}.
+\item un \textit{virtual timer} che calcola il tempo di processore usato dal
+  processo in user space (che corrisponde all'\textit{user time}). La scadenza
+  di questo timer provoca l'emissione di \macro{SIGVTALRM}.
+\item un \textit{profiling timer} che calcola la somma dei tempi di processore
+  utilizzati direttamente dal processo in user space, e dal kernel nelle
+  system call ad esso relative (che corrisponde a quello che in
+  \secref{sec:sys_unix_time} abbiamo chiamato \textit{CPU time}). La scadenza
+  di questo timer provoca l'emissione di \macro{SIGPROF}.
+\end{itemize}
+
+Il timer usato da \func{alarm} è il \textit{clock time}, e corrisponde cioè al
+tempo reale. La funzione, pur essendo molto semplice, presenta numerosi
+limiti: non consente di usare gli altri timer, non può specificare intervalli
+con precisione maggiore del secondo e genera il segnale una sola volta.
+
+Per ovviare a questi limiti Linux deriva da BSD la funzione \func{setitimer}
+che permette di usare un timer qualunque e l'invio di segnali periodici, al
+costo però di una maggiore complessità d'uso e di una minore portabilità. Il
+suo prototipo è:
+\begin{prototype}{sys/time.h}{int setitimer(int which, const struct
+    itimerval *value, struct itimerval *ovalue)} 
+  
+  Predispone l'invio di un segnale di allarme alla scadenza dell'intervallo
+  \param{value} sul timer specificato da \func{which}.
+  
+  \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+    errore, nel qual caso \var{errno} può assumere i valori \macro{EINVAL} e
+    \macro{EFAULT}.}
+\end{prototype}
+
+Il valore di \param{which} permette di specificare quale dei tre timer
+illustrati in precedenza usare; i possibili valori sono riportati in
+\tabref{tab:sig_setitimer_values}.
+\begin{table}[htb]
+  \centering
+  \begin{tabular}[c]{|l|l|}
+    \hline
+    \textbf{Valore} & \textbf{Timer} \\
+    \hline
+    \hline
+    \macro{ITIMER\_REAL}    & \textit{real-time timer}\\
+    \macro{ITIMER\_VIRTUAL} & \textit{virtual timer}\\
+    \macro{ITIMER\_PROF}    & \textit{profiling timer}\\
+    \hline
+  \end{tabular}
+  \caption{Valori dell'argomento \param{which} per la funzione
+    \func{setitimer}.}
+  \label{tab:sig_setitimer_values}
+\end{table}
+
+Il valore della struttura specificata \param{value} viene usato per settare il
+timer, se il puntatore \param{ovalue} non è nullo il precedente valore viene
+salvato qui. I valori dei timer devono essere indicati attraverso una
+struttura \var{itimerval}, definita in \ref{fig:file_stat_struct}.
+
+La struttura è composta da due membri, il primo, \var{it\_interval} definisce
+il periodo del timer; il secondo, \var{it\_value} il tempo mancante alla
+scadenza. Entrambi esprimono i tempi tramite una struttura \var{timeval} che
+permette una precisione fino al microsecondo.
+
+Ciascun timer decrementa il valore di \var{it\_value} fino a zero, poi invia
+il segnale e resetta \var{it\_value} al valore di \var{it\_interval},
+ripetendo il ciclo; se \var{it\_interval} è nullo il timer si ferma.
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+struct itimerval {
+    struct timeval it_interval; /* next value */
+    struct timeval it_value;    /* current value */
+};
+struct timeval {
+    long tv_sec;                /* seconds */
+    long tv_usec;               /* microseconds */
+};
+    \end{lstlisting}
+  \end{minipage} 
+  \normalsize 
+  \caption{La struttura \var{itimerval}, che definisce i valori dei timer di
+    sistema.} 
+  \label{fig:sig_itimerval}
+\end{figure}
+
+L'uso di \func{setitimer} consente dunque un controllo completo di tutte le
+caratteristiche dei timer, ed in effetti la stessa \func{alarm}, benché
+definita direttamente nello standard POSIX.1, può a sua volta essere espressa
+in termini di \func{setitimer}, come evidenziato dal manuale delle \acr{glibc}
+\cite[glibc] che ne riporta la definizione in \figref{fig:sig_alarm_def}.
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+unsigned int alarm(unsigned int seconds)
+{
+    struct itimerval old, new;
+    new.it_interval.tv_usec = 0;
+    new.it_interval.tv_sec = 0;
+    new.it_value.tv_usec = 0;
+    new.it_value.tv_sec = (long int) seconds;
+    if (setitimer(ITIMER_REAL, &new, &old) < 0)
+        return 0;
+    else
+        return old.it_value.tv_sec;
+}
+    \end{lstlisting}
+  \end{minipage} 
+  \normalsize 
+  \caption{Definizione di \func{alarm} in termini di \func{setitimer}.} 
+  \label{fig:sig_alarm_def}
+\end{figure}
+
+Si deve comunque tenere presente che la precisione di queste funzioni è
+limitata da quella del timer di sistema (in genere 10~ms). Il sistema assicura
+comunque che il segnale non sarà mai generato prima della scadenza programmata
+(l'arrotondamento cioè è sempre effettuato per eccesso). Una seconda causa di
+potenziali ritardi è che il segnale viene generato alla scandenza del timer,
+ma poi deve essere consegnato; se il processo è attivo (questo è sempre vero
+per \macro{ITIMER\_VIRT}) la consegna è immediata, altrimenti può esserci un
+ulteriore ritardo che può variare a seconda del carico del sistema.
+
+Dato che sia \func{alarm} che \func{setitimer} non consentono di leggere il
+valore corrente di un timer senza modificarlo, è possibile usare la funzione
+\func{getitimer}, il cui prototipo è:
+\begin{prototype}{sys/time.h}{int getitimer(int which, struct
+    itimerval *value)}
+  
+  Legge in \param{value} il valore del timer specificato da \func{which}.
+  
+  \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+    errore e restituisce gli stessi errori di \func{getitimer}}
+\end{prototype}
+\noindent i cui parametri hanno lo stesso significato e formato di quelli di
+\func{setitimer}. 
+
+
+L'ultima funzione che permette l'invio diretto di un segnale è \func{abort};
+che, come accennato in \ref{sec:proc_termination}, permette di abortire
+l'esecuzione di un programma tramite l'invio di \macro{SIGABRT}. Il suo
+prototipo è:
+\begin{prototype}{stdlib.h}{void abort(void)}
+  
+  Abortisce il processo corrente.
+  
+  \bodydesc{La funzione non ritorna, il processo è terminato inviando il
+  segnale di \macro{SIGABRT}.}
+\end{prototype}
+
+La differenza fra questa funzione e l'uso di \func{raise} è che anche se il
+segnale è bloccato o ignorato, la funzione ha effetto lo stesso. Il segnale
+può però essere intercettato per effettuare eventuali operazioni di chiusura
+prima della terminazione del processo.
+
+Lo standard ANSI C richiede inoltre che anche se il manipolatore ritorna, la
+funzione non ritorni comunque. Lo standard POSIX.1 va oltre e richiede che se
+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}.
+
+
+\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 è:
+\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 manipilatore è ritornato, nel qual caso restituisce -1 e setta
+  \var{errno} a \macro{EINTR}.}
+\end{prototype}
 
 
 
 
-\subsection{Funzioni rientranti e default dei segnali}
-\label{sec:sig_reentrant}
 
 
 
 
+\subsection{Le semantiche di \macro{SIGCHLD}}
+\label{sec:sig_sigchld}
 
 
 
 
 
 
-\subsection{La funzione \func{sigpending}}
+
+\section{Gestione avanzata}
+\label{sec:sig_control}
+
+
+
+
+\subsection{Le funzioni \func{sigprocmask} e \func{sigpending}}
 \label{sec:sig_sigpending}
 
 
 \label{sec:sig_sigpending}
 
 
+
+\subsection{La funzione \func{sigaction}}
+\label{sec:sig_sigaction}
+
+
+
+\subsection{Funzioni rientranti e default dei segnali}
+\label{sec:sig_reentrant}
+
+
+, affrontando inoltre le varie problematiche di programmazione che si devono
+tenere presenti quando si ha a che fare con essi.
+
+
+
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"