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
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
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
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}.
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
\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
\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}
\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}.
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.
\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
(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 è
projects / gapil.git / blobdiff