\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
- \begin{lstlisting}{}
-int sig_handler(); /* handler function */
-int main()
-{
- ...
- signal(SIGINT, sig_handler); /* establish handler */
- ...
-}
-
-int sig_handler()
-{
- signal(SIGINT, sig_handler); /* restablish handler */
- ... /* process signal */
-}
- \end{lstlisting}
+ \includecodesample{listati/unreliable_sig.c}
\end{minipage}
\normalsize
\caption{Esempio di codice di un gestore di segnale per la semantica
\item[\const{SIGTERM}] Il nome sta per \textit{terminate}. È un segnale
generico usato per causare la conclusione di un programma. Al contrario di
\const{SIGKILL} può essere intercettato, ignorato, bloccato. In genere lo si
- usa per chiedere in maniera ``educata'' ad un processo di concludersi.
+ usa per chiedere in maniera ``\textsl{educata}'' ad un processo di
+ concludersi.
\item[\const{SIGINT}] Il nome sta per \textit{interrupt}. È il segnale di
interruzione per il programma. È quello che viene generato di default dal
comando \cmd{kill} o dall'invio sul terminale del carattere di controllo
Raccogliamo qui infine usa serie di segnali che hanno scopi differenti non
classificabili in maniera omogenea. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\const{SIGUSR1}] Vedi \const{SIGUSR2}.
-\item[\const{SIGUSR2}] Insieme a \const{SIGUSR1} è un segnale a disposizione
- dell'utente che li può usare per quello che vuole. Possono essere utili per
- implementare una comunicazione elementare fra processi diversi, o per
- eseguire a richiesta una operazione utilizzando un gestore. L'azione
- predefinita è di terminare il processo.
+\item[\const{SIGUSR1}] Insieme a \const{SIGUSR2} è un segnale a disposizione
+ dell'utente che lo può usare per quello che vuole. Viene generato solo
+ attraverso l'invocazione della funzione \func{kill}. Entrambi i segnali
+ possono essere utili per implementare una comunicazione elementare fra
+ processi diversi, o per eseguire a richiesta una operazione utilizzando un
+ gestore. L'azione predefinita è di terminare il processo.
+\item[\const{SIGUSR2}] È il secondo segnale a dispozione degli utenti. Vedi
+ quanto appena detto per \const{SIGUSR1}.
\item[\const{SIGWINCH}] Il nome sta per \textit{window (size) change} e viene
generato in molti sistemi (GNU/Linux compreso) quando le dimensioni (in
righe e colonne) di un terminale vengono cambiate. Viene usato da alcuni
\func{strsignal} e \func{psignal} è quello di fare usare la variabile
\var{sys\_siglist}, che è definita in \file{signal.h} e può essere acceduta
con la dichiarazione:
-\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
- extern const char *const sys_siglist[]
-\end{lstlisting}
+\includecodesnip{listati/siglist.c}
l'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
indicizzate per numero di segnale, per cui una chiamata del tipo di \code{char
*decr = strsignal(SIGINT)} può essere sostituita dall'equivalente \code{char
In alcuni casi però alcune system call (che per questo motivo vengono chiamate
\textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può
-attendere la conclusione della sistem call, perché questo renderebbe
+attendere la conclusione della system call, perché questo renderebbe
impossibile una risposta pronta al segnale, per cui il gestore viene
eseguito prima che la system call sia ritornata. Un elenco dei casi in cui si
presenta questa situazione è il seguente:
una estensione GNU, definita dalle \acr{glibc}, che permette di riscrivere il
prototipo di \func{signal} nella forma appena vista, molto più leggibile di
quanto non sia la versione originaria, che di norma è definita come:
-\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
- void (*signal(int signum, void (*handler)(int)))int)
-\end{lstlisting}
+\includecodesnip{listati/signal.c}
questa infatti, per la poca chiarezza della sintassi del C quando si vanno a
trattare puntatori a funzioni, è molto meno comprensibile. Da un confronto
con il precedente prototipo si può dedurre la definizione di
\type{sighandler\_t} che è:
-\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
- typedef void (* sighandler_t)(int)
-\end{lstlisting}
+\includecodesnip{listati/sighandler_t.c}
e cioè un puntatore ad una funzione \ctyp{void} (cioè senza valore di ritorno)
e che prende un argomento di tipo \ctyp{int}.\footnote{si devono usare le
parentesi intorno al nome della funzione per via delle precedenze degli
L'uso di \func{signal} è soggetto a problemi di compatibilità, dato che essa
si comporta in maniera diversa per sistemi derivati da BSD o da System V. In
questi ultimi infatti la funzione è conforme al comportamento originale dei
-primi Unix in cui il gestore viene disinstallato alla sua chiamata,
-secondo la semantica inaffidabile; Linux seguiva questa convenzione fino alle
-\acr{libc5}. Al contrario BSD segue la semantica affidabile, non
-disinstallando il gestore e bloccando il segnale durante l'esecuzione
-dello stesso. Con l'utilizzo delle \acr{glibc} dalla versione 2 anche Linux è
-passato a questo comportamento; quello 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}.
-In generale, per evitare questi problemi, tutti i nuovi programmi dovrebbero
-usare \func{sigaction}.
+primi Unix in cui il gestore viene disinstallato alla sua chiamata, secondo la
+semantica inaffidabile; anche Linux seguiva questa convenzione con le vecchie
+librerie del C come le \acr{libc4} e le \acr{libc5}.\footnote{nelle
+ \acr{libc5} esiste però la possibilità di includere \file{bsd/signal.h} al
+ posto di \file{signal.h}, nel qual caso la funzione \func{signal} viene
+ ridefinita per seguire la semantica affidabile usata da BSD.}
+
+Al contrario BSD segue la semantica affidabile, non disinstallando il gestore
+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
+\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}.
È da tenere presente che, seguendo lo standard POSIX, il comportamento di un
processo che ignora i segnali \const{SIGFPE}, \const{SIGILL}, o
-\const{SIGSEGV} (qualora non originino da una \func{kill} o una \func{raise})
-è indefinito. Un gestore che ritorna da questi segnali può dare luogo ad
-un ciclo infinito.
+\const{SIGSEGV} (qualora questi non originino da una chiamata ad una
+\func{kill} o ad una \func{raise}) è indefinito. Un gestore che ritorna da
+questi segnali può dare luogo ad un ciclo infinito.
\subsection{Le funzioni \func{kill} e \func{raise}}
Come accennato in \secref{sec:sig_types}, un segnale può essere generato
direttamente da un processo attraverso una opportuna system call. Le funzioni
-che si usano di solito per invare un segnale generico sono due, \func{raise} e
+che si usano di solito per inviare un segnale generico sono due, \func{raise} e
\func{kill}.
La prima funzione è \funcd{raise}, che è definita dallo standard ANSI C, e
Il valore dell'argomento \param{pid} specifica il processo (o i processi) di
destinazione a cui il segnale deve essere inviato e può assumere i valori
riportati in \tabref{tab:sig_kill_values}.
+
+Si noti pertanto che la funzione \code{raise(sig)} può essere definita in
+termini di \func{kill}, ed è sostanzialmente equivalente ad una
+\code{kill(getpid(), sig)}. Siccome \func{raise}, che è definita nello
+standard ISO C, non esiste in alcune vecchie versioni di Unix, in generale
+l'uso di \func{kill} finisce per essere più portabile.
+
+Una seconda funzione che può essere definita in termini di \func{kill} è
+\funcd{killpg}, che è sostanzialmente equivalente a
+\code{kill(-pidgrp, signal)}; il suo prototipo è:
+\begin{prototype}{signal.h}{int killpg(pid\_t pidgrp, int signal)}
+
+ Invia il segnale \param{signal} al process group \param{pidgrp}.
+ \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ errore, gli errori sono gli stessi di \func{kill}.}
+\end{prototype}
+\noindent e che permette di inviare un segnale a tutto un \textit{process
+ group} (vedi \secref{sec:sess_proc_group}).
+
\begin{table}[htb]
\footnotesize
\centering
\label{tab:sig_kill_values}
\end{table}
-Si noti pertanto che la funzione \code{raise(sig)} può essere definita in
-termini di \func{kill}, ed è sostanzialmente equivalente ad una
-\code{kill(getpid(), sig)}. Siccome \func{raise}, che è definita nello
-standard ISO C, non esiste in alcune vecchie versioni di Unix, in generale
-l'uso di \func{kill} finisce per essere più portabile.
-
-Una seconda funzione che può essere definita in termini di \func{kill} è
-\funcd{killpg}, che è sostanzialmente equivalente a
-\code{kill(-pidgrp, signal)}; il suo prototipo è:
-\begin{prototype}{signal.h}{int killpg(pid\_t pidgrp, int signal)}
-
- Invia il segnale \param{signal} al process group \param{pidgrp}.
- \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, gli errori sono gli stessi di \func{kill}.}
-\end{prototype}
-e che permette di inviare un segnale a tutto un \textit{process group} (vedi
-\secref{sec:sess_proc_group}).
-
Solo l'amministratore può inviare un segnale ad un processo qualunque, in
tutti gli altri casi l'user-ID reale o l'user-ID effettivo del processo
chiamante devono corrispondere all'user-ID reale o all'user-ID salvato della
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
- \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
-struct itimerval
-{
- struct timeval it_interval; /* next value */
- struct timeval it_value; /* current value */
-};
- \end{lstlisting}
+ \includestruct{listati/itimerval.h}
\end{minipage}
\normalsize
\caption{La struttura \structd{itimerval}, che definisce i valori dei timer
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
- \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+ \begin{lstlisting}[stepnumber=0]{}
unsigned int alarm(unsigned int seconds)
{
struct itimerval old, new;
terminazione del processo, cosa che viene eseguita nel ciclo in
(\texttt{\small 15-21}). Il ciclo è necessario a causa di una caratteristica
fondamentale della gestione dei segnali: abbiamo già accennato come fra la
-generazione di un segnale e l'esecuzione del gestore possa passare un
-certo lasso di tempo e niente ci assicura che il gestore venga eseguito
-prima della generazione di ulteriori segnali dello stesso tipo. In questo caso
-normalmente i segnali segnali successivi vengono ``fusi'' col primo ed al
+generazione di un segnale e l'esecuzione del gestore possa passare un certo
+lasso di tempo e niente ci assicura che il gestore venga eseguito prima della
+generazione di ulteriori segnali dello stesso tipo. In questo caso normalmente
+i segnali segnali successivi vengono ``\textsl{fusi}'' col primo ed al
processo ne viene recapitato soltanto uno.
Questo può essere un caso comune proprio con \const{SIGCHLD}, qualora capiti
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
- \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+ \begin{lstlisting}[stepnumber=0]{}
struct sigaction
{
void (*sa_handler)(int);
real-time (vedi \secref{sec:sig_real_time}). In precedenza era possibile
ottenere alcune informazioni addizionali usando \var{sa\_handler} con un
secondo parametro addizionale di tipo \var{sigcontext}, che adesso è
- deprecato.} di utilizzare due forme diverse di gestore, da
-specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO},
-rispettivamente attraverso i campi \var{sa\_sigaction} o \var{sa\_handler},
-(che devono essere usati in maniera alternativa, in certe implementazioni
-questi vengono addirittura definiti come \ctyp{union}): la prima è quella
-classica usata anche con \func{signal}, la seconda permette invece di usare un
-gestore in grado di ricevere informazioni più dettagliate dal sistema,
-attraverso la struttura \struct{siginfo\_t}, riportata in
-\figref{fig:sig_siginfo_t}.
+ deprecato.} di utilizzare due forme diverse di gestore, da specificare, a
+seconda dell'uso o meno del flag \const{SA\_SIGINFO}, rispettivamente
+attraverso i campi \var{sa\_sigaction} o \var{sa\_handler},\footnote{i due
+ tipi devono essere usati in maniera alternativa, in certe implementazioni
+ questi campi vengono addirittura definiti come \ctyp{union}.} Quest'ultima
+è quella classica usata anche con \func{signal}, mentre la prima permette di
+usare un gestore più complesso, in grado di ricevere informazioni più
+dettagliate dal sistema, attraverso la struttura \struct{siginfo\_t},
+riportata in \figref{fig:sig_siginfo_t}.
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
- \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+ \begin{lstlisting}[stepnumber=0]{}
siginfo_t {
int si_signo; /* Signal number */
int si_errno; /* An errno value */
maggiori dettagli riguardo l'errore (come il tipo di errore aritmetico, di
istruzione illecita o di violazione di memoria) mentre alcuni segnali di
controllo (\const{SIGCHLD}, \const{SIGTRAP} e \const{SIGPOLL}) forniscono
-altre informazioni speecifiche. In tutti i casi il valore del campo è
+altre informazioni specifiche. In tutti i casi il valore del campo è
riportato attraverso delle costanti (le cui definizioni si trovano
\file{bits/siginfo.h}) il cui elenco dettagliato è disponibile nella pagina di
manuale di di \func{sigaction}.
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
- \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+ \begin{lstlisting}[stepnumber=0]{}
typedef struct {
void *ss_sp; /* Base address of stack */
int ss_flags; /* Flags */
introdotta in Linux a partire dal kernel 2.1.43(?), e dalle \acr{glibc}
2.1(?).} in particolare sono stati superati tre limiti fondamentali dei
segnali classici:
-\begin{description}
+\begin{basedescript}{\desclabelwidth{1cm}\desclabelstyle{\nextlinelabel}}
\item[I segnali non sono accumulati]
-
se più segnali vengono generati prima dell'esecuzione di un gestore
questo sarà eseguito una sola volta, ed il processo non sarà in grado di
accorgersi di quante volte l'evento che ha generato il segnale è accaduto.
-\item[I segnali non trasportano informazione]
-
+\item[I segnali non trasportano informazione]
i segnali classici non prevedono prevedono altra informazione sull'evento
che li ha generati se non il fatto che sono stati emessi (tutta
l'informazione che il kernel associa ad un segnale è il suo numero).
\item[I segnali non hanno un ordine di consegna]
-
l'ordine in cui diversi segnali vengono consegnati è casuale e non
prevedibile. Non è possibile stabilire una priorità per cui la reazione a
certi segnali ha la precedenza rispetto ad altri.
-\end{description}
+\end{basedescript}
Per poter superare queste limitazioni lo standard ha introdotto delle nuove
caratteristiche, che sono state associate ad una nuova classe di segnali, che
-vengono chiamati \textsl{segnali real-time}, in particolare:
+vengono chiamati \textsl{segnali real-time}, in particolare le funzionalità
+aggiunte sono:
-\begin{itemize*}
+\begin{enumerate}
\item i segnali sono inseriti in una coda che permette di consegnare istanze
multiple dello stesso segnale qualora esso venga inviato più volte prima
dell'esecuzione del gestore; si assicura così che il processo riceva un
\item è stata introdotta una priorità nella consegna dei segnali: i segnali
vengono consegnati in ordine a seconda del loro valore, partendo da quelli
con un numero minore, che pertanto hanno una priorità maggiore.
-\item è stata introdotta la possibilità di restituire dei dati al
- gestore, attraverso l'uso di un campo apposito nella struttura
- \struct{siginfo\_t} accessibile tramite gestori di tipo
+\item è stata introdotta la possibilità di restituire dei dati al gestore,
+ attraverso l'uso di un apposito campo \var{si\_value} nella struttura
+ \struct{siginfo\_t}, accessibile tramite gestori di tipo
\var{sa\_sigaction}.
-\end{itemize*}
+\end{enumerate}
-Queste nuove caratteristiche (eccetto l'ultima, che, come visto in
-\secref{sec:sig_sigaction}, è parzialmente disponibile anche con i segnali
-ordinari) si applicano solo ai nuovi segnali real-time; questi ultimi sono
-accessibili in un range di valori specificati dalle due macro \const{SIGRTMIN}
-e \const{SIGRTMAX},\footnote{in Linux di solito il primo valore è 32, ed il
- secondo \code{\_NSIG-1}, che di norma è 63, per un totale di 32 segnali
- disponibili, contro gli almeno 8 richiesti da POSIX.1b.} che specificano il
-numero minimo e massimo associato ad un segnale real-time.
+Queste nuove funzionalità (eccetto l'ultima, che, come vedremo, è parzialmente
+disponibile anche con i segnali ordinari) si applicano solo ai nuovi segnali
+real-time; questi ultimi sono accessibili in un range di valori specificati
+dalle due macro \const{SIGRTMIN} e \const{SIGRTMAX},\footnote{in Linux di
+ solito il primo valore è 32, ed il secondo \code{\_NSIG-1}, che di norma è
+ 63, per un totale di 32 segnali disponibili, contro gli almeno 8 richiesti
+ da POSIX.1b.} che specificano il numero minimo e massimo associato ad un
+segnale real-time.
I segnali con un numero più basso hanno una priorità maggiore e vengono
consegnati per primi, inoltre i segnali real-time non possono interrompere
real-time.
Si tenga presente che questi nuovi segnali non sono associati a nessun evento
-sepcifico (a meno di non utilizzarli, come vedremo in
-\secref{sec:file_asyncronous_io}, per l'I/O asincrono) e devono essere inviati
-esplicitamente. Tutti i segnali real-time restituiscono al gestore, oltre ai
-campi \var{si\_pid} e \var{si\_uid} di \struct{siginfo\_t} una struttura
-\struct{sigval} (riportata in \figref{fig:sig_sigval}) in cui può essere
-restituito al processo un valore o un indirizzo, che costituisce il meccanismo
-con cui il segnale è in grado di inviare una ulteriore informazione al
-processo.
+specifico, a meno di non utilizzarli in meccanismi di notifica come quelli per
+l'I/O asincrono (vedi \secref{sec:file_asyncronous_io}) o per le code di
+messaggi POSIX (vedi \secref{sec:ipc_posix_mq}); pertanto devono essere
+inviati esplicitamente.
+
+Inoltre per poter usufruire della capacità di restituire dei dati i relativi
+gestori devono essere installati con \func{sigaction} specificando la modalità
+\const{SA\_SIGINFO} che permette di utilizzare la forma estesa
+\var{sa\_sigaction} (vedi \secref{sec:sig_sigaction}). In questo modo tutti i
+segnali real-time possono restituire al gestore una serie di informazioni
+aggiuntive attraverso l'argomento \struct{siginfo\_t} (la cui definizione è
+riportata in \figref{fig:sig_siginfo_t}).
+
+In particolare i campi utilizzati dai segnali real-time sono \var{si\_pid} e
+\var{si\_uid} in cui vengono memorizzati rispettivamente \acr{pid} e userid
+effettivo del processo che ha inviato il segnale, mentre per la restituzione
+dei dati viene usato il campo \var{si\_value}, questo è una \ctyp{union} di
+tipo \struct{sigval\_t} (la sua definizione è in \figref{fig:sig_sigval}) in
+cui può essere memorizzato o un valore numerico o un indirizzo,\footnote{un
+ campo di tipo \struct{sigval\_t} è presente anche nella struttura
+ \struct{sigevent} che viene usata dai meccanismi di notifica come quelli per
+ l'I/O asincrono (vedi \secref{sec:file_asyncronous_io}) o le code di
+ messaggi POSIX (vedi \secref{sec:ipc_posix_mq}).}
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
- \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
-union sigval {
+ \begin{lstlisting}[stepnumber=0]{}
+union sigval_t {
int sival_int;
void *sival_ptr;
}
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \structd{sigval}, usata dai segnali real time per
- restituire dati al gestore.}
+ \caption{La struttura \structd{sigval\_t}, una \ctyp{union} usata dai
+ segnali real-time e dai meccanismi di notifica per restituire dati al
+ gestore, (in alcune definizione essa viene identificata anche come
+ \code{union sigval}).}
\label{fig:sig_sigval}
\end{figure}
-A causa di queste loro caratteristiche, la funzione \func{kill} non è adatta
-ad inviare un segnale real time, in quanto non è in grado di fornire alcun
-valore per \struct{sigval}; per questo motivo lo standard ha previsto una
-nuova funzione, \funcd{sigqueue}, il cui prototipo è:
+A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
+inviare segnali real-time, poichè non è in grado di fornire alcun valore
+per \struct{sigval\_t}; per questo motivo lo standard ha previsto una nuova
+funzione, \funcd{sigqueue}, il cui prototipo è:
\begin{prototype}{signal.h}
- {int sigqueue(pid\_t pid, int signo, const union sigval value)}
+ {int sigqueue(pid\_t pid, int signo, const sigval\_t value)}
Invia il segnale \param{signo} al processo \param{pid}, restituendo al
gestore il valore \param{value}.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EAGAIN}] La coda è esarita, ci sono già \const{SIGQUEUE\_MAX}
+ \item[\errcode{EAGAIN}] La coda è esaurita, ci sono già \const{SIGQUEUE\_MAX}
segnali in attesa si consegna.
\item[\errcode{EPERM}] Non si hanno privilegi appropriati per inviare il
segnale al processo specificato.
Se il segnale è bloccato la funzione ritorna immediatamente, se si è
installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili,
-vale a dire che c'è posto nella coda\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 \secref{sec:sys_limits}. Il suo valore minimo secondo lo
- standard, \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32.}, esso viene inserito
-e diventa pendente; una volta consegnato riporterà nel campo \var{si\_code} di
-\struct{siginfo} 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.
+(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
+ \secref{sec:sys_limits}. Il suo valore minimo secondo lo standard,
+ \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32.} nella coda) esso viene
+inserito e diventa pendente; una volta consegnato riporterà nel campo
+\var{si\_code} di \struct{siginfo} 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
\func{sigwait}, ai quali si aggiunge, per \func{sigtimedwait}:
\begin{errlist}
\item[\errcode{EAGAIN}] Si è superato il timeout senza che un segnale atteso
- fosse emmesso.
+ fosse emesso.
\end{errlist}
}
\end{functions}
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à
+di timeout nullo, e non ci sono segnali 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
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
%%% TeX-master: "gapil"
+%%% TeX-master: "gapil"
%%% End:
projects / gapil.git / blobdiff