X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=59d28704a94022447e8e29eb4cbcfaba85122781;hp=ea8454e2555c90322f0e83db3d7db492d783e634;hb=1e09a8256d97540694702ac3952f36281542bc60;hpb=017baa9ca8e1da7c8951d269125cfab35c427e08

diff --git a/signal.tex b/signal.tex
index ea8454e..59d2870 100644
--- a/signal.tex
+++ b/signal.tex
@@ -2,9 +2,9 @@
 \label{cha:signals}
 
 I segnali sono il primo e più semplice meccanismo di comunicazione nei
-confronti dei processi. Non portano con sé nessuna informazione che non sia il
-loro tipo; si tratta in sostanza di un'interruzione software portata ad un
-processo.
+confronti dei processi. Nella loro versione originale essi portano con sé
+nessuna informazione che non sia il loro tipo; si tratta in sostanza di
+un'interruzione software portata ad un processo.
 
 In genere essi vengono usati dal kernel per riportare ai processi situazioni
 eccezionali (come errori di accesso, eccezioni aritmetiche, etc.) ma possono
@@ -16,7 +16,8 @@ In questo capitolo esamineremo i vari aspetti della gestione dei segnali,
 partendo da una introduzione relativa ai concetti base con cui essi vengono
 realizzati, per poi affrontarne la classificazione a secondo di uso e modalità
 di generazione fino ad esaminare in dettaglio funzioni e le metodologie di
-gestione. 
+gestione avanzate e le estensioni fatte all'interfaccia classica nelle nuovi
+versioni dello standard POSIX.
 
 
 \section{Introduzione}
@@ -2468,10 +2469,99 @@ disponibili, vale a dire che c'
 e diventa pendente; una volta consegnato riporterà nel campo \var{si\_code} di
 \var{siginfo} il valore \macro{SI\_QUEUE} e il campo \var{si\_value} riceverà
 quanto inviato con \param{value}. Se invece si è installato un manipolatore
-nella forma classica il segnale sarà generato, ma in caso di emissioni
-multiple prima dell'esecuzione del manipolatore, sarà ricevuto una sola volta.
+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
+modo nel caso dei thread, in cui si possono usare i segnali real-time come
+meccanismi di comunicazione elementare; la prima di queste funzioni è
+\func{sigwait}, il cui prototipo è:
+\begin{prototype}{signal.h}
+  {int sigwait(const sigset\_t *set, int *sig)}
+  
+  Attende che uno dei segnali specificati in \param{set} sia pendente.
+  
+  \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+    errore, nel qual caso \var{errno} viene settata ai valori:
+  \begin{errlist}
+  \item[\macro{EINTR}] La funzione è stata interrotta.
+  \item[\macro{EINVAL}] Si è specificato un valore non valido per
+    \param{set}.
+  \end{errlist}
+  ed inoltre \macro{EFAULT}.}
+\end{prototype}
 
+La funzione estrae dall'insieme dei segnali pendenti uno qualunque dei segnali
+specificati da \param{set}, il cui valore viene restituito in \param{sig}.  Se
+sono pendenti più segnali, viene estratto quello a priorità più alta (cioè con
+il numero più basso). Se, nel caso di segnali real-time, c'è più di un segnale
+pendente, ne verrà estratto solo uno. Una volta estratto il segnale non verrà
+più consegnato, e se era in una coda il suo posto sarà liberato.  Se non c'è
+nessun segnale pendente il processo viene bloccato fintanto che non ne arriva
+uno.
+
+Per un funzionamento corretto la funzione richiede che alla sua chiamata i
+segnali di \param{set} siano bloccati. In caso contrario si avrebbe un
+conflitto con gli eventuali manipolatori: pertanto non si deve utilizzare per
+lo stesso segnale questa funzione e \func{sigaction}. Se questo non avviene il
+comportamento del sistema è indeterminato: il segnale può sia essere
+consegnato che essere ricevuto da \func{sigwait}, il tutto in maniera non
+prevedibile.
+
+Lo standard POSIX.1b definisce altre due funzioni, anch'esse usate
+prevalentemente con i thread; \func{sigwaitinfo} e \func{sigtimedwait}, i
+relativi prototipi sono:
+\begin{functions}
+  \headdecl{signal.h}   
+
+  \funcdecl{int sigwaitinfo(const sigset\_t *set, siginfo\_t *info)}  
+  
+  Analoga a \func{sigwait}, ma riceve anche le informazioni associate al
+  segnale in \param{info}.
+  
+  \funcdecl{int sigtimedwait(const sigset\_t *set, siginfo\_t *value, const
+    struct timespec *info)}
+  
+  Analoga a \func{sigwaitinfo}, con un la possibilità di specificare un
+  timeout in \param{timeout}.
+
+  
+  \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
+    errore, nel qual caso \var{errno} viene settata ai valori già visti per
+    \func{sigwait}, ai quali se aggiunge, per \func{sigtimedwait}:
+  \begin{errlist}
+  \item[\macro{EAGAIN}] Si è superato il timeout senza che un segnale atteso
+    fosse emmesso.
+  \end{errlist}
+}
+\end{functions}
 
+Entrambe le funzioni sono estensioni di \func{sigwait}. La prima permette di
+ricevere, oltre al numero del segnale, anche le informazioni ad esso associate
+tramite \param{info}; in particolare viene restituito il numero del segnale
+nel campo \var{si\_signo}, la sua causa in \var{si\_code}, e se il segnale è
+stato immesso sulla coda con \func{sigqueue}, il valore di ritorno ad esso
+associato viene riportato in \var{si\_value}, che altrimenti è indefinito. 
+
+La seconda è identica alla prima ma in più permette di specificare un timeout,
+scaduto il quale ritornerà con un errore. Se si specifica un puntatore nullo
+il comportamento sarà identico a \func{sigwaitinfo}, se si specifica un tempo
+di timeout nullo, e non ci sono sengali pendenti la funzione ritornerà
+immediatamente; in questo modo si può eliminare un segnale dalla coda senza
+dover essere bloccati qualora esso non sia presente.
+
+
+L'uso di queste funzioni è principalmente associato alla gestione dei segnali
+com i thread. In genere esse vengono chiamate dal thread incaricato della
+gestione, che al ritorno della funzione esegue il codice che usualmente
+sarebbe messo nel manipolatore, per poi ripetere la chiamata per mettersi in
+attesa del segnale successivo. Questo ovviamente comporta che non devono
+essere installati manipolatori, che solo il thread di gestione deve usare
+\func{sigwait} e che, per evitare che venga eseguita l'azione di default, i
+segnali gestiti in questa maniera devono essere mascherati per tutti i thread,
+compreso quello dedicato alla gestione, che potrebbe riceverlo fra due
+chiamate successive.
 
 %%% Local Variables: 
 %%% mode: latex