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
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
\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}.
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
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
-%%% TeX-master: "gapil"
%%% End:
projects / gapil.git / blobdiff