X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=c28a70c33e0ae189dbf4e5856efe5edc89b7e9ce;hp=525e8598c4ce35677b0f71a38bac1fbd1d8108ae;hb=cf60963212306540ce7485ed7c86405e143a3352;hpb=6377acba6d39c62ceff07a420e0028bf6e03408c diff --git a/signal.tex b/signal.tex index 525e859..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}[stepnumber=0,frame=]{} - 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}[stepnumber=0,frame=]{} - 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}[stepnumber=0,frame=]{} - 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}[stepnumber=0]{} -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 @@ -2626,4 +2609,5 @@ dedicato alla gestione, che potrebbe riceverlo fra due chiamate successive. %%% Local Variables: %%% mode: latex %%% TeX-master: "gapil" +%%% TeX-master: "gapil" %%% End: