Risistemazioni varie, lavori in corso
[gapil.git] / signal.tex
index 98e476eb52ef57e99ef2390f23b4b12bfd916482..966e32a1aa0759a2d1d6b15210171c3f2680d5e7 100644 (file)
@@ -84,8 +84,7 @@ attivo.
 In questo caso è possibile una situazione in cui i segnali possono essere
 perduti. Si consideri il seguente segmento di codice, in cui la prima
 operazione del manipolatore è quella di reinstallare se stesso: 
 In questo caso è possibile una situazione in cui i segnali possono essere
 perduti. Si consideri il seguente segmento di codice, in cui la prima
 operazione del manipolatore è quella di reinstallare se stesso: 
-s
-e un secondo segnale arriva prima che il manipolatore invocato dal primo
+se un secondo segnale arriva prima che il manipolatore invocato dal primo
 abbia eseguito la reinstallazione di se stesso il segnale può essere perso o
 causare il comportamento originale assegnato al segnale (in genere la
 terminazione del processo).
 abbia eseguito la reinstallazione di se stesso il segnale può essere perso o
 causare il comportamento originale assegnato al segnale (in genere la
 terminazione del processo).
@@ -883,11 +882,11 @@ con il precedente prototipo si pu
 \begin{verbatim}
     typedef void (* sighandler_t)(int) 
 \end{verbatim}
 \begin{verbatim}
     typedef void (* sighandler_t)(int) 
 \end{verbatim}
-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
+e cioè un puntatore ad una funzione \ctyp{void} (cioè senza valore di ritorno)
+e che prende un argomento di tipo \ctyp{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
   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}.}
+  un puntatore a \ctyp{void} e non un puntatore ad una funzione \ctyp{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.
 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.
@@ -957,6 +956,15 @@ la funzione \func{kill}; il cui prototipo 
   \headdecl{signal.h}
   \funcdecl{int kill(pid\_t pid, int sig)} Invia il segnale \param{sig} al
   processo specificato con \param{pid}.
   \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 0 in caso di successo e -1 in caso di
+    errore nel qual caso \var{errno} può assumere i valori:
+    \begin{errlist}
+    \item[\macro{EINVAL}] Il segnale specificato non esiste.
+    \item[\macro{ESRCH}] Il processo selezionato non esiste.
+    \item[\macro{EPERM}] Non si hanno privilegi sufficienti ad inviare il
+      segnale.
+    \end{errlist}}
 \end{functions}
 
 Lo standard POSIX prevede che il valore 0 per \param{sig} sia usato per
 \end{functions}
 
 Lo standard POSIX prevede che il valore 0 per \param{sig} sia usato per
@@ -992,7 +1000,6 @@ riportati in \tabref{tab:sig_kill_values}.
   \label{tab:sig_kill_values}
 \end{table}
 
   \label{tab:sig_kill_values}
 \end{table}
 
-
 Si noti pertanto che la funzione \code{raise(sig)} può essere definita in
 termini di \func{kill}, ed è sostanzialmente equivalente ad una
 \code{kill(getpid(), sig)}. Siccome \func{raise}, che è definita nello
 Si noti pertanto che la funzione \code{raise(sig)} può essere definita in
 termini di \func{kill}, ed è sostanzialmente equivalente ad una
 \code{kill(getpid(), sig)}. Siccome \func{raise}, che è definita nello
@@ -1493,7 +1500,7 @@ fino a trattare le caratteristiche generali della gestione dei medesimi nella
 casistica ordinaria.
 
 
 casistica ordinaria.
 
 
-\subsection{Un esempio di problema}
+\subsection{Alcune problematiche aperte}
 \label{sec:sig_example}
 
 Come accennato in \secref{sec:sig_pause_sleep} è possibile implementare
 \label{sec:sig_example}
 
 Come accennato in \secref{sec:sig_pause_sleep} è possibile implementare
@@ -1532,7 +1539,8 @@ unsigned int sleep(unsigned int seconds)
     /* remove alarm, return remaining time */
     return alarm(0);
 }
     /* remove alarm, return remaining time */
     return alarm(0);
 }
-void alarm_hand(int sig) {
+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");
     /* check if the signal is the right one */
     if (sig != SIGALRM) { /* if not exit with error */
         printf("Something wrong, handler for SIGALRM\n");
@@ -1585,7 +1593,8 @@ unsigned int sleep(unsigned int seconds)
     /* remove alarm, return remaining time */
     return alarm(0);
 }
     /* remove alarm, return remaining time */
     return alarm(0);
 }
-void alarm_hand(int sig) {
+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");
     /* check if the signal is the right one */
     if (sig != SIGALRM) { /* if not exit with error */
         printf("Something wrong, handler for SIGALRM\n");
@@ -1612,20 +1621,121 @@ 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
 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 i segnali in maniera più completa.
+principale, interrompendone inopportunamente l'esecuzione.  
 
 
+Lo stesso tipo di problema si presenterebbe se si volesse usare \func{alarm}
+per stabilire un timeout su una sistem call bloccante. Un secondo esempio è
+quello in cui si usa il segnale per notificare una quelche forma di evento; in
+genere quello che si fa in questo caso è settare nel manipolatore un opportuno
+flag da controllare nel corpo principale del programma (con un codice del tipo
+di quello riportato in 
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}{}
+sig_atomic_t flag;
+unsigned int control(unsigned int seconds)
+{
+    da fare
+}
+void alarm_hand(int sig) 
+{
+    /* set the flag 
+    flag = 1;
+}      
+    \end{lstlisting}
+  \end{minipage} 
+  \normalsize 
+  \caption{Un esempio non funzionante di restituzione di un evento da parte di
+    un segnale.} 
+  \label{fig:sig_event_wrong}
+\end{figure}
+
+
+
+È per questo motivo che occorrono funzioni più sofisticate della semplice
+\func{signal} che permettano di gestire i segnali in maniera più completa.
+
+
+
+
+
+
+\subsection{I \textit{signal set}}
+\label{sec:sig_sigset}
+
+Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali
+dei primi Unix, nate con la semantica inaffidabile, hanno dei limiti non
+superabili; in particolare non è prevista nessuna funzione che permetta di
+gestire gestire il blocco dei segnali o di verificare lo stato dei segnali
+pendenti.
+
+Per questo motivo lo standard POSIX.1, insieme alla nuova semantica dei
+segnali ha introdotto una interfaccia di gestione completamente nuova, che
+permette di ottenete un controllo molto più dettagliato. In particolare lo
+standard ha introdotto un nuovo tipo di dato \type{sigset\_t}, che permette di
+rappresentare un insieme di segnali (un \textit{signal set}, come viene
+usualmente chiamato), che è il tipo di dato che viene usato per gestire il
+blocco dei segnali.
+
+In genere un \textit{signal set} è rappresentato da un intero di dimensione
+opportuna, di solito si pari al numero di bit dell'architettura della
+macchina\footnote{nel caso dei PC questo comporta un massimo di 32 segnali
+  distinti, dato che in Linux questi sono sufficienti non c'è necessità di
+  nessuna struttura più complicata.}, ciascun bit del quale è associato ad uno
+specifico segnale; in questo modo è di solito possibile implementare le
+operazioni direttamente con istruzioni elementari del processore; lo standard
+POSIX.1 definisce cinque funzioni per la manipolazione dei \textit{signal set},
+\func{sigemptyset}, \func{sigfillset}, \func{sigaddset}, \func{sigdelset} e
+\func{sigismember}, i cui prototipi sono:
+\begin{functions}
+  \headdecl{signal.h} 
+
+  \funcdecl{int sigemptyset(sigset\_t *set)} Inizializza un \textit{signal set}
+  vuoto.
+  \funcdecl{int sigfillset(sigset\_t *set)} Inizializza un \textit{signal set}
+  pieno (con tutti i segnali).
+  
+  \funcdecl{int sigaddset(sigset\_t *set, int signum)} Aggiunge il segnale
+  \param{signum} al  \textit{signal set} \param{set}.
+
+  \funcdecl{int sigdelset(sigset\_t *set, int signum)} Toglie il segnale
+  \param{signum} dal \textit{signal set} \param{set}.
+  
+  \funcdecl{int sigismember(const sigset\_t *set, int signum)} Controlla se il
+  segnale \param{signum} è nel \textit{signal set} \param{set}
+  
+  \bodydesc{Le prime quattro funzioni ritornano 0 in caso di successo, mentre
+    \func{sigismember} ritorna 1 se \param{signum} è in \param{set} e 0
+    altrimenti. In caso di errore tutte ritornano -1, con \var{errno} settata a
+    \macro{EINVAL} (il solo errore possibile è che \param{signum} non sia un
+    segnale valido).}
+\end{functions}
+
+Dato che in generale non si può fare conto sulle caratteristiche di una
+implementazione (non è detto che si disponga di un numero di bit sufficienti
+per mettere tutti i segnali in un intero, o in \type{sigset\_t} possono essere
+immagazzinate ulteriori informazioni) tutte le operazioni devono essere
+comunque eseguite attraverso queste funzioni.
+
+In genere si usa un \textit{signal set} per specificare quali segnali si vuole
+bloccare, o per riottenere dalle varie funzioni di gestione la maschera dei
+segnali attivi. Essi possono essere definiti in due diverse maniere,
+aggiungendo i segnali voluti ad un insieme vuoto ottenuto con
+\func{sigemptyset} o togliendo quelli che non servono da un insieme completo
+ottenuto con \func{sigfillset}. Infine \func{sigismember} permette di vericare
+la presenza di uno specifico segnale in un \textit{signal set}.
 
 
 \subsection{La funzione \func{sigaction}}
 \label{sec:sig_sigaction}
 
 
 
 \subsection{La funzione \func{sigaction}}
 \label{sec:sig_sigaction}
 
-Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali
-dei primi Unix, hanno dei limiti non superabili; per questo motivo lo standard
-POSIX ha introdotto una interfaccia di gestione completamente nuova, che
-permette un controllo molto più dettagliato. La funzione principale di questa
-nuova interfaccia è \func{sigaction}; il cui prototipo è:
+La funzione principale dell'interfaccia standard POSIX.1 per i segnali è
+\func{sigaction}, essa ha sostanzialemente le stesse funzioni di
+\func{signal}, permette cioè di specificare come un segnale può essere gestito
+da un processo. Il suo prototipo è:
 
 \begin{prototype}{signal.h}{int sigaction(int signum, const struct sigaction
     *act, struct sigaction *oldact)} 
 
 \begin{prototype}{signal.h}{int sigaction(int signum, const struct sigaction
     *act, struct sigaction *oldact)} 
@@ -1642,25 +1752,25 @@ nuova interfaccia 
   \end{errlist}}
 \end{prototype}
 
   \end{errlist}}
 \end{prototype}
 
-La funzione serve ad installare una nuova azione per il segnale
-\param{signum}; si parla di azione e non di manipolatore come nel caso di
-\func{signal}, in quanto la funzione consente di specificare le varie
-caratteristiche della risposta al segnale, non solo la funzione del
-manipolatore.  Lo standard POSIX raccomanda di usare sempre questa funzione al
-posto di \func{signal} (che in genere viene definita tramite essa), in quanto
-offre un controllo completo, sia pure al prezzo di una maggiore complessità
-d'uso.
+La funzione serve ad installare una nuova \textsl{azione} per il segnale
+\param{signum}; si parla di \textsl{azione} e non di \textsl{manipolatore}
+come nel caso di \func{signal}, in quanto la funzione consente di specificare
+le varie caratteristiche della risposta al segnale, non solo la funzione del
+manipolatore.  Per questo lo standard raccomanda di usare sempre questa
+funzione al posto di \func{signal} (che in genere viene definita tramite
+essa), in quanto offre un controllo completo su tutti gli aspetti della
+gestione di un segnale, sia pure al prezzo di una maggiore complessità d'uso.
 
 
-Se il puntatore \param{act} non è nullo la funzione installa la nuova azione
+Se il puntatore \param{act} non è nullo, la funzione installa la nuova azione
 da esso specificata, se \param{oldact} non è nullo il valore dell'azione
 corrente viene restituito indietro.  Questo permette (specificando \param{act}
 nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
 che non consente di ottenere l'azione corrente senza installarne una nuova.
 
 da esso specificata, se \param{oldact} non è nullo il valore dell'azione
 corrente viene restituito indietro.  Questo permette (specificando \param{act}
 nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
 che non consente di ottenere l'azione corrente senza installarne una nuova.
 
-Entrambi i puntatori fanno riferimento alla struttura \var{sigaction}, che
-permette di descrivere tutte le caratteristiche dell'azione associata ad un
-segnale.  Anch'essa è descritta dallo standard POSIX ed in Linux è definita
-secondo quanto riportato in \secref{fig:sig_sigaction}, il campo
+Entrambi i puntatori fanno riferimento alla struttura \var{sigaction}, tramite
+la quale si specificano tutte le caratteristiche dell'azione associata ad un
+segnale.  Anch'essa è descritta dallo standard POSIX.1 ed in Linux è definita
+secondo quanto riportato in \figref{fig:sig_sigaction}. Il campo
 \var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
 più usato.
 
 \var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
 più usato.
 
@@ -1668,7 +1778,8 @@ pi
   \footnotesize \centering
   \begin{minipage}[c]{15cm}
     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
   \footnotesize \centering
   \begin{minipage}[c]{15cm}
     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
-struct sigaction {
+struct sigaction 
+{
     void (*sa_handler)(int);
     void (*sa_sigaction)(int, siginfo_t *, void *);
     sigset_t sa_mask;
     void (*sa_handler)(int);
     void (*sa_sigaction)(int, siginfo_t *, void *);
     sigset_t sa_mask;
@@ -1682,9 +1793,95 @@ struct sigaction {
   \label{fig:sig_sigaction}
 \end{figure}
 
   \label{fig:sig_sigaction}
 \end{figure}
 
+Come si può notare da quanto riportato in \figref{fig:sig_sigaction} in Linux
+\func{sigaction} permette di specificare il manipolatore in due forme diverse,
+indicate dai campi \var{sa\_handler} e \var{sa\_sigaction}; esse devono essere
+usate in maniera alternativa (in certe implementazioni questi vengono
+specificati come \ctyp{union}): la prima è quella classica usata anche con
+\func{signal}, la seconda permette invece di usare un manipolatore in grado di
+ricevere informazioni più dettagliate dal sistema (ad esempio il tipo di
+errore in caso di \macro{SIGFPE}), attraverso dei parametri aggiuntivi; per i
+dettagli si consulti la man page di \func{sigaction}).
+
+Il campo \var{sa\_mask} serve ad indicare l'insieme dei segnali che devono
+essere bloccati durante l'esecuzione del manipolatore, ad essi viene comunque
+sempre aggiunto il segnale che ne ha causato la chiamata, a meno che non si
+sia specificato con \var{sa\_flag} un comportamento diverso.
+
+Il valore di \var{sa\_flag} permette di specificare vari aspetti del
+comportamento di \func{sigaction}, e della reazione del processo ai vari
+segnali; i valori possibili ed il relativo significato sono riportati in
+\tabref{tab:sig_sa_flag}. 
+
+\begin{table}[htb]
+  \footnotesize
+  \centering
+  \begin{tabular}[c]{|l|p{8cm}|}
+    \hline
+    \textbf{Valore} & \textbf{Timer} \\
+    \hline
+    \hline
+    \macro{SA\_NOCLDSTOP}& Se il segnale è \macro{SIGCHLD} allora non deve
+    essere notificato quando il processo figlio viene fermato da uno dei
+    segnali \macro{SIGSTOP}, \macro{SIGTSTP}, \macro{SIGTTIN} or 
+    \macro{SIGTTOU}.\\
+    \macro{SA\_ONESHOT}  & Ristabilisce l'azione per il segnale al valore di
+    default una volta che il manipolatore è stato lanciato, riproduce cioè il
+    comportamento della semantica inaffidabile.\\
+    \macro{SA\_RESETHAND}& Sinonimo di \macro{SA\_ONESHOT}. \\
+    \macro{SA\_RESTART}  & Riavvia automaticamente le \textit{slow system
+    call} quando vengono interrotte dal suddetto segnale; riproduce cioè il
+    comportamento standard di BSD.\\
+    \macro{SA\_NOMASK}   & Evita che il segnale corrente sia bloccato durante
+    l'esecuzione del manipolatore.\\
+    \macro{SA\_NODEFER}  & Sinonimo di  \macro{SA\_NOMASK}.\\
+    \macro{SA\_SIGINFO}  & Deve essere specificato quando si vuole usare un
+    manipolatore in forma estesa usando \var{sa\_sigaction} al posto di
+    \var{sa\_handler}. \\
+    \macro{SA\_ONSTACK}   & Stabilisce l'uso di uno stack alternativo per
+    l'esecuzione del manipolatore (vedi \secref{sec:sig_altstack}).\\
+    \hline
+  \end{tabular}
+  \caption{Valori del campo \var{sa\_flag} della struttura \var{sigaction}.}
+  \label{tab:sig_sa_flag}
+\end{table}
+
+Benché sia possibile usare nello stesso programma sia \func{sigaction} che
+\func{signal} occorre molta attenzione, in quanto le due funzioni possono
+interagire in maniera anomala. Infatti l'azione specificata con
+\var{sigaction} contiene un maggior numero di informazioni rispetto al
+semplice indirizzo del manipolatore restituito da \func{signal}.  Per questo
+motivo se si usa quest'ultima per installare un manipolatore sostituendone uno
+precedentemente installato con \func{sigaction}, non sarà possibile effettuare
+un ripristino corretto dello stesso.
+
+Per questo è sempre opportuno usare \func{sigaction}, che è in grado di
+ripristinare correttamente un manipolatore precedente, anche se questo è stato
+installato con \func{signal}. In generale poi non è il caso di usare il valore
+di ritorno di \func{signal} come campo \var{sa\_handler}, o viceversa, dato
+che in certi sistemi questi possono essere diversi. In generale dunque, a meno
+che non si sia vincolati allo standard ISO C, è sempre il caso di evitare
+l'uso di \func{signal} a favore di \func{sigaction}.
+
+
+
+\subsection{La gestione del blocco dei segnali}
+\label{sec:sig_sigmask}
+
+Come spiegato in \secref{sec:sig_semantics} tutti i moderni sistemi unix-like
+permettono si bloccare temporaneamente (o di eliminare completamente, settando
+\macro{SIG\_IGN} come azione) la consegna dei segnali ad un processo. Questo è
+fatto specificando la cosiddetta \textit{signal mask} del
+processo\footnote{nel caso di Linux essa è mantenuta dal campo \var{blocked}
+  della relativa \var{task\_struct}} che viene espressa come il signal set dei
+segnali la cui consegna è bloccata. Abbiamo accennato in
+\secref{sec:proc_fork} che la \textit{signal mask} viene ereditata dal padre
+alla creazione di un processo figlio, e abbiamo visto al paragrafo precedente
+che essa può essere specificata, durante l'esecuzione di un manipolatore,
+attraverso l'uso dal campo \var{sa\_mask} di \var{sigaction}.
+
+Uno dei problemi evidenziatisi con l'esempio di 
 
 
-\subsection{I \textit{signal set}}
-\label{sec:sig_sigset}
 
 
 \subsection{Le funzioni \func{sigpending} e \func{sigsuspend}}
 
 
 \subsection{Le funzioni \func{sigpending} e \func{sigsuspend}}