X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=625a65b131999ea702f09d6dd32da3fe30fe93b6;hp=dca91653837ba38ea38b9aa402b75ea2a1a8c249;hb=5af25bf51719d4f435f57a8d7df64f286ad64996;hpb=7b6b988cdddf6e996eb88d02bd13bbe7e2936d73

diff --git a/signal.tex b/signal.tex
index dca9165..625a65b 100644
--- a/signal.tex
+++ b/signal.tex
@@ -1,6 +1,6 @@
-a%% signal.tex
+%% signal.tex
 %%
-%% Copyright (C) 2000-2002 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2003 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 "Prefazione",
@@ -212,15 +212,19 @@ scheduler\index{scheduler} che esegue l'azione specificata. Questo a meno che
 il segnale in questione non sia stato bloccato prima della notifica, nel qual
 caso l'invio non avviene ed il segnale resta \textsl{pendente}
 indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
-notificato.
+notificato. Si tenga presente però che i segnali \textsl{pendenti} non si
+accodano, alla generazione infatti il kernel marca un flag nella
+\struct{task\_struct} del processo, per cui se prima della notifica ne vengono
+generati altri il flag è comunque marcato, ed il gestore viene eseguito sempre
+una sola volta.
 
 Si ricordi però che se l'azione specificata per un segnale è quella di essere
 ignorato questo sarà scartato immediatamente al momento della sua generazione,
-e questo anche se in quel momento il segnale è bloccato (perché ciò che viene
-bloccata è la notifica). Per questo motivo un segnale, fintanto che viene
-ignorato, non sarà mai notificato, anche se è stato bloccato ed in seguito si
-è specificata una azione diversa (nel qual caso solo i segnali successivi alla
-nuova specificazione saranno notificati).
+e questo anche se in quel momento il segnale è bloccato (perché bloccare su un
+segnale significa bloccarne è la notifica). Per questo motivo un segnale,
+fintanto che viene ignorato, non sarà mai notificato, anche se prima è stato
+bloccato ed in seguito si è specificata una azione diversa (nel qual caso solo
+i segnali successivi alla nuova specificazione saranno notificati).
 
 Una volta che un segnale viene notificato (che questo avvenga subito o dopo
 una attesa più o meno lunga) viene eseguita l'azione specificata per il
@@ -584,8 +588,8 @@ L'azione predefinita 
   questo può essere usato anche per i file, posto che la \func{fcntl} abbia
   avuto successo.
 \item[\const{SIGURG}] Questo segnale è inviato quando arrivano dei dati
-  urgenti o \textit{out of band} su di un socket\index{socket}; per maggiori
-  dettagli al proposito si veda \secref{sec:xxx_urgent_data}.
+  urgenti o \textit{out-of-band} su di un socket\index{socket}; per maggiori
+  dettagli al proposito si veda \secref{sec:TCP_urgent_data}.
 \item[\const{SIGPOLL}] Questo segnale è equivalente a \const{SIGIO}, è
   definito solo per compatibilità con i sistemi System V.
 \end{basedescript}
@@ -651,13 +655,13 @@ 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 è necessario che, prima che un processo inizi a scrivere su di
-  essa, un'altro abbia aperto la pipe in lettura (si veda
+\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
+  scrivere su una di esse, che un'altro l'abbia aperta in lettura (si veda
   \secref{sec:ipc_pipes}). Se il processo in lettura non è partito o è
   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} 
+  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.
@@ -781,13 +785,13 @@ programmi eseguiti in background, che altrimenti sarebbero interrotti da una
 successiva pressione di \texttt{C-c} o \texttt{C-y}.
 
 Per quanto riguarda il comportamento di tutte le altre system call si danno
-sostanzialmente due casi, a seconda che esse siano \textsl{lente}
-(\textit{slow}) o \textsl{veloci} (\textit{fast}). La gran parte di esse
-appartiene a quest'ultima categoria, che non è influenzata dall'arrivo di un
-segnale. Esse sono dette \textsl{veloci} in quanto la loro esecuzione è
-sostanzialmente immediata; la risposta al segnale viene sempre data dopo che
-la system call è stata completata, in quanto attendere per eseguire un
-gestore non comporta nessun inconveniente.
+sostanzialmente due casi, a seconda che esse siano\index{system call lente}
+\textsl{lente} (\textit{slow}) o \textsl{veloci} (\textit{fast}). La gran
+parte di esse appartiene a quest'ultima categoria, che non è influenzata
+dall'arrivo di un segnale. Esse sono dette \textsl{veloci} in quanto la loro
+esecuzione è sostanzialmente immediata; la risposta al segnale viene sempre
+data dopo che la system call è stata completata, in quanto attendere per
+eseguire un gestore non comporta nessun inconveniente.
 
 In alcuni casi però alcune system call (che per questo motivo vengono chiamate
 \textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può
@@ -826,10 +830,11 @@ ripetendo l'esecuzione dell'espressione \var{expr} fintanto che il risultato
 non è diverso dall'uscita con un errore \errcode{EINTR}.
 
 La soluzione è comunque poco elegante e BSD ha scelto un approccio molto
-diverso, che è quello di fare ripartire automaticamente la system call invece
-di farla fallire. In questo caso ovviamente non c'è da preoccuparsi di
-controllare il codice di errore; si perde però la possibilità di eseguire
-azioni specifiche all'occorrenza di questa particolare condizione. 
+diverso, che è quello di fare ripartire automaticamente una system call
+interrotta invece di farla fallire. In questo caso ovviamente non c'è bisogno
+di preoccuparsi di controllare il codice di errore; si perde però la
+possibilità di eseguire azioni specifiche all'occorrenza di questa particolare
+condizione.
 
 Linux e le \acr{glibc} consentono di utilizzare entrambi gli approcci,
 attraverso una opportuna opzione di \func{sigaction} (vedi
@@ -912,7 +917,7 @@ 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
+chiamando \func{sysv\_signal}, una 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}.
@@ -1737,7 +1742,7 @@ in \tabref{tab:sig_sa_flag}.
     \const{SA\_RESTART}  & Riavvia automaticamente le \textit{slow system
                            call} quando vengono interrotte dal suddetto
                            segnale; riproduce cioè il comportamento standard
-                           di BSD.\\ 
+                           di BSD.\index{system call lente}\\ 
     \const{SA\_NOMASK}   & Evita che il segnale corrente sia bloccato durante
                            l'esecuzione del gestore.\\
     \const{SA\_NODEFER}  & Sinonimo di \const{SA\_NOMASK}.\\
@@ -2328,15 +2333,17 @@ Se il segnale 
 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
+  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 dei segnali
-real-time) esso viene inserito e diventa pendente; una volta consegnato
-riporterà nel campo \var{si\_code} di \struct{siginfo\_t} 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.
+  \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 è
+  di 1024.} nella coda dei segnali real-time) esso viene inserito e diventa
+pendente; una volta consegnato riporterà nel campo \var{si\_code} di
+\struct{siginfo\_t} 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
@@ -2431,5 +2438,4 @@ dedicato alla gestione, che potrebbe riceverlo fra due chiamate successive.
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"
-%%% TeX-master: "gapil"
 %%% End: