Messi un po' di placeholder per i terminali virtuali e UDP, corretti alcuni

[gapil.git] / signal.tex

diff --git a/signal.tex b/signal.tex
index c426986c6c029892481a0684bbf7edf65ef65582..625a65b131999ea702f09d6dd32da3fe30fe93b6 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -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
 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,
 
 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
 
 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


@@ -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
 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
 
 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
 \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}.
 \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}.


@@ -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
 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,
   \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
 
 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"
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"

-%%% TeX-master: "gapil"

 %%% End: 
 %%% End: