inoltre sarà possibile stabilire delle priorità nella risposta a seconda del
segnale usato. In questo modo si può identificare immediatamente un file su
cui l'accesso è diventato possibile evitando completamente l'uso di funzioni
-come \func{poll} e \func{select}.
+come \func{poll} e \func{select}, almeno fintanto che non si satura la coda;
+si eccedono le dimensioni di quest'ultima; in tal caso infatti il kernel, non
+potendo più assicurare il comportamento corretto per un segnale real-time,
+invierà al suo posto un \var{SIGIO}, su cui si accumuleranno tutti i segnali
+in eccesso, e si dovra determinare al solito modo quali sono i file diventati
+attivi.
+
+
Benché la modalità di apertura asincrona di un file possa risultare utile in
varie occasioni (in particolar modo con i socket e gli altri file per i quali
\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
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}
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; la prima di queste è
+\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{EINVAL}] Si è specificato un valore non valido per
+ \param{set}.
+ \end{errlist}
+ ed inoltre \macro{EFAULT}.}
+\end{prototype}
+
+
+Altre due funzioni, usate prevalentemente con i thread, sono
+\func{sigwaitinfo} e \func{sigtimedwait}, i loro prototipi sono:
+\begin{functions}
+ \headdecl{signal.h}
+
+ \funcdecl{int sigwaitinfo(const sigset\_t *set, siginfo\_t *info)}
+
+ Attende che uno dei segnali specificati in \param{set} sia pendente.
+
+ \funcdecl{int sigtimedwait(const sigset\_t *set, siginfo\_t *info, const
+ struct timespec *timeout)}
+
+ 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{EINVAL}] Si è specificato un valore non valido per
+ \item[\macro{EAGAIN}] La coda è esarita, ci sono già \macro{SIGQUEUE\_MAX}
+ segnali in attesa si consegna.
+ \item[\macro{EINTR}] Non si hanno privilegi appropriati per inviare il
+ segnale al processo specificato.
+ \item[\macro{ENOSYS}] Il processo \param{pid} non esiste.
+ \param{set}.
+ \end{errlist}
+ ed inoltre \macro{EFAULT}.}
+\end{functions}
+
+