X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=signal.tex;h=60514f5ef5d9be1fe6e64b848eca71e04df0fb02;hb=bf81ce9ec539254693a8c41641a99af1aa1d886f;hp=13c8d77f76adfe150b4216629ea074412925c692;hpb=b93afedb7d7b01ba1f0b5ea4caaa281f38cb8e6d;p=gapil.git diff --git a/signal.tex b/signal.tex index 13c8d77..60514f5 100644 --- a/signal.tex +++ b/signal.tex @@ -1,6 +1,6 @@ %% signal.tex %% -%% Copyright (C) 2000-2004 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2005 Simone Piccardi. Permission is granted to %% copy, distribute and/or modify this document under the terms of the GNU Free %% Documentation License, Version 1.1 or any later version published by the %% Free Software Foundation; with the Invariant Sections being "Un preambolo", @@ -433,16 +433,13 @@ processo che li ha causati. In genere oltre a questo il segnale provoca pure la registrazione su disco di un file di \textit{core dump} che viene scritto in un file \file{core} nella directory corrente del processo al momento dell'errore, che il debugger può usare per ricostruire lo stato del programma -al momento della terminazione. - -Questi segnali sono: +al momento della terminazione. Questi segnali sono: \begin{basedescript}{\desclabelwidth{2.0cm}} \item[\const{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome derivi da \textit{floating point exception} si applica a tutti gli errori - aritmetici compresa la divisione per zero e l'overflow. - - Se il gestore ritorna il comportamento del processo è indefinito, ed - ignorare questo segnale può condurre ad un ciclo infinito. + aritmetici compresa la divisione per zero e l'overflow. Se il gestore + ritorna il comportamento del processo è indefinito, ed ignorare questo + segnale può condurre ad un ciclo infinito. % Per questo segnale le cose sono complicate dal fatto che possono esserci % molte diverse eccezioni che \texttt{SIGFPE} non distingue, mentre lo @@ -578,9 +575,8 @@ sempre la necessit Questi segnali operano in congiunzione con le funzioni di I/O asincrono. Per questo occorre comunque usare \func{fcntl} per abilitare un file descriptor a -generare questi segnali. - -L'azione predefinita è di essere ignorati. Questi segnali sono: +generare questi segnali. L'azione predefinita è di essere ignorati. Questi +segnali sono: \begin{basedescript}{\desclabelwidth{2.0cm}} \item[\const{SIGIO}] Questo segnale viene inviato quando un file descriptor è pronto per eseguire dell'input/output. In molti sistemi solo i @@ -651,10 +647,8 @@ cui si trattano gli argomenti relativi. Questi segnali sono: Questi segnali sono usati per riportare al programma errori generati da operazioni da lui eseguite; non indicano errori del programma quanto errori che impediscono il completamento dell'esecuzione dovute all'interazione con il -resto del sistema. - -L'azione predefinita di questi segnali è di terminare il processo, questi -segnali sono: +resto del sistema. L'azione predefinita di questi segnali è di terminare il +processo, questi segnali sono: \begin{basedescript}{\desclabelwidth{2.0cm}} \item[\const{SIGPIPE}] Sta per \textit{Broken pipe}. Se si usano delle pipe, (o delle FIFO o dei socket) è necessario, prima che un processo inizi a @@ -663,9 +657,12 @@ segnali sono: terminato inavvertitamente alla scrittura sulla pipe il kernel genera questo segnale. Se il segnale è bloccato, intercettato o ignorato la chiamata che lo ha causato fallisce, restituendo l'errore \errcode{EPIPE}. -\item[\const{SIGLOST}] Sta per \textit{Resource lost}. Viene generato quando - c'è un advisory lock su un file NFS, ed il server riparte dimenticando la - situazione precedente. +\item[\const{SIGLOST}] Sta per \textit{Resource lost}. Tradizionalmente è il + segnale che generato quando si ha un advisory lock su un file su NFS che + viene perso perché il server NFS è stato riavviato. Il progetto GNU lo + utilizza per indicare ad un client il crollo inaspettato di un server. In + Linux è definito come sinonimo di \const{SIGIO}.\footnote{ed è segnalato + come BUG nella pagina di manuale.} \item[\const{SIGXCPU}] Sta per \textit{CPU time limit exceeded}. Questo segnale è generato quando un processo eccede il limite impostato per il tempo di CPU disponibile, vedi sez.~\ref{sec:sys_resource_limit}. @@ -805,9 +802,10 @@ presenta questa situazione presenti (come per certi file di dispositivo\index{file!di~dispositivo}, i socket\index{socket} o le pipe). \item la scrittura sugli stessi file, nel caso in cui dati non possano essere - accettati immediatamente. + accettati immediatamente (di nuovo comune per i socket). \item l'apertura di un file di dispositivo che richiede operazioni non - immediate per una risposta. + immediate per una risposta (ad esempio l'apertura di un nastro che deve + essere riavvolto). \item le operazioni eseguite con \func{ioctl} che non è detto possano essere eseguite immediatamente. \item le funzioni di intercomunicazione che si bloccano in attesa di risposte @@ -817,12 +815,12 @@ presenta questa situazione \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 gestore -sia ritornato. La scelta originaria dei primi Unix era quella di far ritornare +In questo caso si pone il problema di cosa fare una volta che il gestore sia +ritornato. La scelta originaria dei primi Unix era quella di far ritornare anche la system call restituendo l'errore di \errcode{EINTR}. Questa è a tutt'oggi una scelta corrente, ma comporta che i programmi che usano dei -gestori controllino lo stato di uscita delle funzioni per ripeterne la -chiamata qualora l'errore fosse questo. +gestori controllino lo stato di uscita delle funzioni che eseguono una system +call lenta per ripeterne la chiamata qualora l'errore fosse questo. Dimenticarsi di richiamare una system call interrotta da un segnale è un errore comune, tanto che le \acr{glibc} provvedono una macro @@ -848,13 +846,13 @@ ritornano sempre indicando i byte trasferiti. \label{sec:sig_signal} L'interfaccia più semplice per la gestione dei segnali è costituita dalla -funzione \funcd{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 +funzione \funcd{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à in alcune vecchie implementazioni (SVr4 e 4.3+BSD in particolare) vengono usati - alcuni parametri aggiuntivi per definire il comportamento della funzione, + alcuni argomenti aggiuntivi per definire il comportamento della funzione, vedremo in sez.~\ref{sec:sig_sigaction} che questo è possibile usando la funzione \func{sigaction}.} che è: \begin{prototype}{signal.h} @@ -1214,7 +1212,7 @@ valore corrente di un timer senza modificarlo, \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 +\noindent i cui argomenti hanno lo stesso significato e formato di quelli di \func{setitimer}. @@ -1341,7 +1339,7 @@ POSIX1.b, il cui prototipo Lo standard richiede che la funzione sia implementata in maniera del tutto indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto utilizzando direttamente il timer del kernel.} e sia utilizzabile senza -interferenze con l'uso di \const{SIGALRM}. La funzione prende come parametri +interferenze con l'uso di \const{SIGALRM}. La funzione prende come argomenti delle strutture di tipo \struct{timespec}, la cui definizione è riportata in fig.~\ref{fig:sys_timeval_struct}, che permettono di specificare un tempo con una precisione (teorica) fino al nanosecondo. @@ -1764,21 +1762,21 @@ in tab.~\ref{tab:sig_sa_flag}. \label{tab:sig_sa_flag} \end{table} -Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} -permette\footnote{La possibilità è prevista dallo standard POSIX.1b, ed è - stata aggiunta nei kernel della serie 2.1.x con l'introduzione dei segnali - real-time (vedi sez.~\ref{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},\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 fig.~\ref{fig:sig_siginfo_t}. +Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette +di utilizzare due forme diverse di gestore,\footnote{La possibilità è prevista + dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x + con l'introduzione dei segnali real-time (vedi + sez.~\ref{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.} 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 fig.~\ref{fig:sig_siginfo_t}. \begin{figure}[!htb] \footnotesize \centering @@ -2343,7 +2341,7 @@ installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili, (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 - sez.~\ref{sec:sys_limits}. Il suo valore minimo secondo lo standard, + sez.~\ref{sec:sys_limits}; il suo valore minimo secondo lo standard, \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux questo è uno dei parametri del kernel impostabili sia con \func{sysctl}, che scrivendolo direttamente in \file{/proc/sys/kernel/rtsig-max}, il valore predefinito è