X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=c28a70c33e0ae189dbf4e5856efe5edc89b7e9ce;hp=250653effe452aa10211384610f120972708f64e;hb=cf60963212306540ce7485ed7c86405e143a3352;hpb=9b0f636834e8d92e87131bbb99d7d846bab1421a diff --git a/signal.tex b/signal.tex index 250653e..c28a70c 100644 --- a/signal.tex +++ b/signal.tex @@ -105,21 +105,7 @@ verr \begin{figure}[!htb] \footnotesize \centering \begin{minipage}[c]{15cm} - \begin{lstlisting}{} -int sig_handler(); /* handler function */ -int main() -{ - ... - signal(SIGINT, sig_handler); /* establish handler */ - ... -} - -int sig_handler() -{ - signal(SIGINT, sig_handler); /* restablish handler */ - ... /* process signal */ -} - \end{lstlisting} + \includecodesample{listati/unreliable_sig.c} \end{minipage} \normalsize \caption{Esempio di codice di un gestore di segnale per la semantica @@ -691,12 +677,14 @@ segnali sono: Raccogliamo qui infine usa serie di segnali che hanno scopi differenti non classificabili in maniera omogenea. Questi segnali sono: \begin{basedescript}{\desclabelwidth{2.0cm}} -\item[\const{SIGUSR1}] Vedi \const{SIGUSR2}. -\item[\const{SIGUSR2}] Insieme a \const{SIGUSR1} è un segnale a disposizione - dell'utente che li può usare per quello che vuole. Possono essere utili per - implementare una comunicazione elementare fra processi diversi, o per - eseguire a richiesta una operazione utilizzando un gestore. L'azione - predefinita è di terminare il processo. +\item[\const{SIGUSR1}] Insieme a \const{SIGUSR2} è un segnale a disposizione + dell'utente che lo può usare per quello che vuole. Viene generato solo + attraverso l'invocazione della funzione \func{kill}. Entrambi i segnali + possono essere utili per implementare una comunicazione elementare fra + processi diversi, o per eseguire a richiesta una operazione utilizzando un + gestore. L'azione predefinita è di terminare il processo. +\item[\const{SIGUSR2}] È il secondo segnale a dispozione degli utenti. Vedi + quanto appena detto per \const{SIGUSR1}. \item[\const{SIGWINCH}] Il nome sta per \textit{window (size) change} e viene generato in molti sistemi (GNU/Linux compreso) quando le dimensioni (in righe e colonne) di un terminale vengono cambiate. Viene usato da alcuni @@ -740,9 +728,7 @@ Una modalit \func{strsignal} e \func{psignal} è quello di fare usare la variabile \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} +\includecodesnip{listati/siglist.c} 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 @@ -879,16 +865,12 @@ In questa definizione si una estensione GNU, definita dalle \acr{glibc}, che permette di riscrivere il prototipo di \func{signal} nella forma appena vista, molto più leggibile di quanto non sia la versione originaria, che di norma è definita come: -\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} - void (*signal(int signum, void (*handler)(int)))int) -\end{lstlisting} +\includecodesnip{listati/signal.c} 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{lstlisting}[labelstep=0,frame=,indent=1cm]{} - typedef void (* sighandler_t)(int) -\end{lstlisting} +\includecodesnip{listati/sighandler_t.c} 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 @@ -918,22 +900,28 @@ 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 gestore 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 -disinstallando il gestore e bloccando il segnale durante l'esecuzione -dello stesso. Con l'utilizzo delle \acr{glibc} dalla versione 2 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}. +primi Unix in cui il gestore viene disinstallato alla sua chiamata, secondo la +semantica inaffidabile; anche Linux seguiva questa convenzione con le vecchie +librerie del C come le \acr{libc4} e le \acr{libc5}.\footnote{nelle + \acr{libc5} esiste però la possibilità di includere \file{bsd/signal.h} al + posto di \file{signal.h}, nel qual caso la funzione \func{signal} viene + ridefinita per seguire la semantica affidabile usata da BSD.} + +Al contrario BSD segue la semantica affidabile, non disinstallando il gestore +e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo delle +\acr{glibc} dalla versione 2 anche Linux è passato a questo comportamento. Il +comportamento 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}, uno volta che si sia definita la macro +\macro{\_XOPEN\_SOURCE}. In generale, per evitare questi problemi, l'uso di +\func{signal} (ed ogni eventuale ridefinizine della stessa) è da evitare; +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 \const{SIGFPE}, \const{SIGILL}, o -\const{SIGSEGV} (qualora non originino da una \func{kill} o una \func{raise}) -è indefinito. Un gestore che ritorna da questi segnali può dare luogo ad -un ciclo infinito. +\const{SIGSEGV} (qualora questi non originino da una chiamata ad una +\func{kill} o ad una \func{raise}) è indefinito. Un gestore che ritorna da +questi segnali può dare luogo ad un ciclo infinito. \subsection{Le funzioni \func{kill} e \func{raise}} @@ -998,6 +986,25 @@ esso sia realmente quello a cui si intendeva mandare il segnale. Il valore dell'argomento \param{pid} specifica il processo (o i processi) di destinazione a cui il segnale deve essere inviato e può assumere i valori riportati in \tabref{tab:sig_kill_values}. + +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 +standard ISO C, non esiste in alcune vecchie versioni di Unix, in generale +l'uso di \func{kill} finisce per essere più portabile. + +Una seconda funzione che può essere definita in termini di \func{kill} è +\funcd{killpg}, che è sostanzialmente equivalente a +\code{kill(-pidgrp, signal)}; il suo prototipo è: +\begin{prototype}{signal.h}{int killpg(pid\_t pidgrp, int signal)} + + Invia il segnale \param{signal} al process group \param{pidgrp}. + \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di + errore, gli errori sono gli stessi di \func{kill}.} +\end{prototype} +\noindent e che permette di inviare un segnale a tutto un \textit{process + group} (vedi \secref{sec:sess_proc_group}). + \begin{table}[htb] \footnotesize \centering @@ -1019,24 +1026,6 @@ riportati in \tabref{tab:sig_kill_values}. \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 -standard ISO C, non esiste in alcune vecchie versioni di Unix, in generale -l'uso di \func{kill} finisce per essere più portabile. - -Una seconda funzione che può essere definita in termini di \func{kill} è -\funcd{killpg}, che è sostanzialmente equivalente a -\code{kill(-pidgrp, signal)}; il suo prototipo è: -\begin{prototype}{signal.h}{int killpg(pid\_t pidgrp, int signal)} - - Invia il segnale \param{signal} al process group \param{pidgrp}. - \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di - errore, gli errori sono gli stessi di \func{kill}.} -\end{prototype} -e che permette di inviare un segnale a tutto un \textit{process group} (vedi -\secref{sec:sess_proc_group}). - Solo l'amministratore può inviare un segnale ad un processo qualunque, in tutti gli altri casi l'user-ID reale o l'user-ID effettivo del processo chiamante devono corrispondere all'user-ID reale o all'user-ID salvato della @@ -1164,13 +1153,7 @@ questo modo il ciclo verr \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 */ -}; - \end{lstlisting} + \includestruct{listati/itimerval.h} \end{minipage} \normalsize \caption{La struttura \structd{itimerval}, che definisce i valori dei timer @@ -1188,7 +1171,7 @@ in termini di \func{setitimer}, come evidenziato dal manuale delle \acr{glibc} \begin{figure}[!htb] \footnotesize \centering \begin{minipage}[c]{15cm} - \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{} + \begin{lstlisting}[stepnumber=0]{} unsigned int alarm(unsigned int seconds) { struct itimerval old, new; @@ -1811,7 +1794,7 @@ pi \begin{figure}[!htb] \footnotesize \centering \begin{minipage}[c]{15cm} - \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{} + \begin{lstlisting}[stepnumber=0]{} struct sigaction { void (*sa_handler)(int); @@ -1889,20 +1872,20 @@ permette\footnote{La possibilit real-time (vedi \secref{sec:sig_real_time}). In precedenza era possibile ottenere alcune informazioni addizionali usando \var{sa\_handler} con un secondo parametro addizionale di tipo \var{sigcontext}, che adesso è - deprecato.} di utilizzare due forme diverse di gestore, da -specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO}, -rispettivamente attraverso i campi \var{sa\_sigaction} o \var{sa\_handler}, -(che devono essere usati in maniera alternativa, in certe implementazioni -questi vengono addirittura definiti come \ctyp{union}): la prima è quella -classica usata anche con \func{signal}, la seconda permette invece di usare un -gestore in grado di ricevere informazioni più dettagliate dal sistema, -attraverso la struttura \struct{siginfo\_t}, riportata in -\figref{fig:sig_siginfo_t}. + deprecato.} di utilizzare due forme diverse di gestore, da specificare, a +seconda dell'uso o meno del flag \const{SA\_SIGINFO}, rispettivamente +attraverso i campi \var{sa\_sigaction} o \var{sa\_handler},\footnote{i due + tipi devono essere usati in maniera alternativa, in certe implementazioni + questi campi vengono addirittura definiti come \ctyp{union}.} Quest'ultima +è quella classica usata anche con \func{signal}, mentre la prima permette di +usare un gestore più complesso, in grado di ricevere informazioni più +dettagliate dal sistema, attraverso la struttura \struct{siginfo\_t}, +riportata in \figref{fig:sig_siginfo_t}. \begin{figure}[!htb] \footnotesize \centering \begin{minipage}[c]{15cm} - \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{} + \begin{lstlisting}[stepnumber=0]{} siginfo_t { int si_signo; /* Signal number */ int si_errno; /* An errno value */ @@ -2298,7 +2281,7 @@ successivo ripristino). \begin{figure}[!htb] \footnotesize \centering \begin{minipage}[c]{15cm} - \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{} + \begin{lstlisting}[stepnumber=0]{} typedef struct { void *ss_sp; /* Base address of stack */ int ss_flags; /* Flags */ @@ -2396,30 +2379,28 @@ presenta dei significativi miglioramenti,\footnote{questa estensione introdotta in Linux a partire dal kernel 2.1.43(?), e dalle \acr{glibc} 2.1(?).} in particolare sono stati superati tre limiti fondamentali dei segnali classici: -\begin{description} +\begin{basedescript}{\desclabelwidth{1cm}\desclabelstyle{\nextlinelabel}} \item[I segnali non sono accumulati] - se più segnali vengono generati prima dell'esecuzione di un gestore questo sarà eseguito una sola volta, ed il processo non sarà in grado di accorgersi di quante volte l'evento che ha generato il segnale è accaduto. -\item[I segnali non trasportano informazione] - +\item[I segnali non trasportano informazione] i segnali classici non prevedono prevedono altra informazione sull'evento che li ha generati se non il fatto che sono stati emessi (tutta l'informazione che il kernel associa ad un segnale è il suo numero). \item[I segnali non hanno un ordine di consegna] - l'ordine in cui diversi segnali vengono consegnati è casuale e non prevedibile. Non è possibile stabilire una priorità per cui la reazione a certi segnali ha la precedenza rispetto ad altri. -\end{description} +\end{basedescript} Per poter superare queste limitazioni lo standard ha introdotto delle nuove caratteristiche, che sono state associate ad una nuova classe di segnali, che -vengono chiamati \textsl{segnali real-time}, in particolare: +vengono chiamati \textsl{segnali real-time}, in particolare le funzionalità +aggiunte sono: -\begin{itemize*} +\begin{enumerate} \item i segnali sono inseriti in una coda che permette di consegnare istanze multiple dello stesso segnale qualora esso venga inviato più volte prima dell'esecuzione del gestore; si assicura così che il processo riceva un @@ -2427,20 +2408,20 @@ vengono chiamati \textsl{segnali real-time}, in particolare: \item è stata introdotta una priorità nella consegna dei segnali: i segnali vengono consegnati in ordine a seconda del loro valore, partendo da quelli con un numero minore, che pertanto hanno una priorità maggiore. -\item è stata introdotta la possibilità di restituire dei dati al - gestore, attraverso l'uso di un campo apposito nella struttura - \struct{siginfo\_t} accessibile tramite gestori di tipo +\item è stata introdotta la possibilità di restituire dei dati al gestore, + attraverso l'uso di un apposito campo \var{si\_value} nella struttura + \struct{siginfo\_t}, accessibile tramite gestori di tipo \var{sa\_sigaction}. -\end{itemize*} +\end{enumerate} -Queste nuove caratteristiche (eccetto l'ultima, che, come visto in -\secref{sec:sig_sigaction}, è parzialmente disponibile anche con i segnali -ordinari) si applicano solo ai nuovi segnali real-time; questi ultimi sono -accessibili in un range di valori specificati dalle due macro \const{SIGRTMIN} -e \const{SIGRTMAX},\footnote{in Linux di solito il primo valore è 32, ed il - secondo \code{\_NSIG-1}, che di norma è 63, per un totale di 32 segnali - disponibili, contro gli almeno 8 richiesti da POSIX.1b.} che specificano il -numero minimo e massimo associato ad un segnale real-time. +Queste nuove funzionalità (eccetto l'ultima, che, come vedremo, è parzialmente +disponibile anche con i segnali ordinari) si applicano solo ai nuovi segnali +real-time; questi ultimi sono accessibili in un range di valori specificati +dalle due macro \const{SIGRTMIN} e \const{SIGRTMAX},\footnote{in Linux di + solito il primo valore è 32, ed il secondo \code{\_NSIG-1}, che di norma è + 63, per un totale di 32 segnali disponibili, contro gli almeno 8 richiesti + da POSIX.1b.} che specificano il numero minimo e massimo associato ad un +segnale real-time. I segnali con un numero più basso hanno una priorità maggiore e vengono consegnati per primi, inoltre i segnali real-time non possono interrompere @@ -2450,37 +2431,54 @@ tutti la stessa priorit real-time. Si tenga presente che questi nuovi segnali non sono associati a nessun evento -specifico (a meno di non utilizzarli, come vedremo in -\secref{sec:file_asyncronous_io}, per l'I/O asincrono) e devono essere inviati -esplicitamente. Tutti i segnali real-time restituiscono al gestore, oltre ai -campi \var{si\_pid} e \var{si\_uid} di \struct{siginfo\_t} una struttura -\struct{sigval} (riportata in \figref{fig:sig_sigval}) in cui può essere -restituito al processo un valore o un indirizzo, che costituisce il meccanismo -con cui il segnale è in grado di inviare una ulteriore informazione al -processo. +specifico, a meno di non utilizzarli in meccanismi di notifica come quelli per +l'I/O asincrono (vedi \secref{sec:file_asyncronous_io}) o per le code di +messaggi POSIX (vedi \secref{sec:ipc_posix_mq}); pertanto devono essere +inviati esplicitamente. + +Inoltre per poter usufruire della capacità di restituire dei dati i relativi +gestori devono essere installati con \func{sigaction} specificando la modalità +\const{SA\_SIGINFO} che permette di utilizzare la forma estesa +\var{sa\_sigaction} (vedi \secref{sec:sig_sigaction}). In questo modo tutti i +segnali real-time possono restituire al gestore una serie di informazioni +aggiuntive attraverso l'argomento \struct{siginfo\_t} (la cui definizione è +riportata in \figref{fig:sig_siginfo_t}). + +In particolare i campi utilizzati dai segnali real-time sono \var{si\_pid} e +\var{si\_uid} in cui vengono memorizzati rispettivamente \acr{pid} e userid +effettivo del processo che ha inviato il segnale, mentre per la restituzione +dei dati viene usato il campo \var{si\_value}, questo è una \ctyp{union} di +tipo \struct{sigval\_t} (la sua definizione è in \figref{fig:sig_sigval}) in +cui può essere memorizzato o un valore numerico o un indirizzo,\footnote{un + campo di tipo \struct{sigval\_t} è presente anche nella struttura + \struct{sigevent} che viene usata dai meccanismi di notifica come quelli per + l'I/O asincrono (vedi \secref{sec:file_asyncronous_io}) o le code di + messaggi POSIX (vedi \secref{sec:ipc_posix_mq}).} \begin{figure}[!htb] \footnotesize \centering \begin{minipage}[c]{15cm} - \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{} -union sigval { + \begin{lstlisting}[stepnumber=0]{} +union sigval_t { int sival_int; void *sival_ptr; } \end{lstlisting} \end{minipage} \normalsize - \caption{La struttura \structd{sigval}, usata dai segnali real time per - restituire dati al gestore.} + \caption{La struttura \structd{sigval\_t}, una \ctyp{union} usata dai + segnali real-time e dai meccanismi di notifica per restituire dati al + gestore, (in alcune definizione essa viene identificata anche come + \code{union sigval}).} \label{fig:sig_sigval} \end{figure} -A causa di queste loro caratteristiche, la funzione \func{kill} non è adatta -ad inviare un segnale real time, in quanto non è in grado di fornire alcun -valore per \struct{sigval}; per questo motivo lo standard ha previsto una -nuova funzione, \funcd{sigqueue}, il cui prototipo è: +A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad +inviare segnali real-time, poichè non è in grado di fornire alcun valore +per \struct{sigval\_t}; per questo motivo lo standard ha previsto una nuova +funzione, \funcd{sigqueue}, il cui prototipo è: \begin{prototype}{signal.h} - {int sigqueue(pid\_t pid, int signo, const union sigval value)} + {int sigqueue(pid\_t pid, int signo, const sigval\_t value)} Invia il segnale \param{signo} al processo \param{pid}, restituendo al gestore il valore \param{value}. @@ -2506,16 +2504,17 @@ di errore senza inviare nessun segnale. Se il segnale è bloccato la funzione ritorna immediatamente, se si è installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili, -vale a dire che c'è posto nella coda\footnote{la profondità della coda è - indicata dalla costante \const{SIGQUEUE\_MAX}, una della tante costanti di - sistema definite dallo standard POSIX, che non abbiamo riportato - esplicitamente in \secref{sec:sys_limits}. Il suo valore minimo secondo lo - standard, \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32.}, esso viene inserito -e diventa pendente; una volta consegnato riporterà nel campo \var{si\_code} di -\struct{siginfo} il valore \const{SI\_QUEUE} e il campo \var{si\_value} -riceverà quanto inviato con \param{value}. Se invece si è installato un -gestore nella forma classica il segnale sarà generato, ma tutte le -caratteristiche tipiche dei segnali real-time (priorità e coda) saranno perse. +(vale a dire che c'è posto\footnote{la profondità della coda è indicata dalla + costante \const{SIGQUEUE\_MAX}, una della tante costanti di sistema definite + dallo standard POSIX, che non abbiamo riportato esplicitamente in + \secref{sec:sys_limits}. Il suo valore minimo secondo lo standard, + \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32.} nella coda) esso viene +inserito e diventa pendente; una volta consegnato riporterà nel campo +\var{si\_code} di \struct{siginfo} il valore \const{SI\_QUEUE} e il campo +\var{si\_value} riceverà quanto inviato con \param{value}. Se invece si è +installato un gestore nella forma classica il segnale sarà generato, ma tutte +le caratteristiche tipiche dei segnali real-time (priorità e coda) saranno +perse. Lo standard POSIX.1b definisce inoltre delle nuove funzioni che permettono di gestire l'attesa di segnali specifici su una coda, esse servono in particolar @@ -2596,7 +2595,6 @@ di timeout nullo, e non ci sono segnali pendenti la funzione ritorner immediatamente; in questo modo si può eliminare un segnale dalla coda senza dover essere bloccati qualora esso non sia presente. - L'uso di queste funzioni è principalmente associato alla gestione dei segnali com i thread. In genere esse vengono chiamate dal thread incaricato della gestione, che al ritorno della funzione esegue il codice che usualmente @@ -2607,7 +2605,9 @@ che, per evitare che venga eseguita l'azione predefinita, i segnali gestiti in questa maniera devono essere mascherati per tutti i thread, compreso quello dedicato alla gestione, che potrebbe riceverlo fra due chiamate successive. + %%% Local Variables: %%% mode: latex %%% TeX-master: "gapil" +%%% TeX-master: "gapil" %%% End: