parametro->argomento dove dovuto, ed inoltre sistemata la tabellina sugli

[gapil.git] / signal.tex

diff --git a/signal.tex b/signal.tex
index c34a7d32946ffd6f8cab99bb259b460f99ab667f..60514f5ef5d9be1fe6e64b848eca71e04df0fb02 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -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
 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
 \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
 
 %   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
 
 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
 \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
 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
 \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}.
   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}. 
 \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
   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
 \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 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*}
 
 \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
 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
 
 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
 \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
 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}
   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}
   \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}. 
 
 
 \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
 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.
 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}
 
   \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
 
 \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
 (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 è
   \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 è