\signal{SIGXCPU} &BS& C & Ecceduto il limite sul tempo di CPU.\\
\signal{SIGXFSZ} &BS& C & Ecceduto il limite sulla dimensione dei file.\\
\signal{SIGVTALRM}&BS& T& Timer di esecuzione scaduto.\\
- \signal{SIGPROF} &BS& T & Timer del profiling scaduto.\\
+ \signal{SIGPROF} &BS& T & Timer del \textit{profiling} scaduto.\\
\signal{SIGWINCH}&B & I & Finestra ridimensionata (4.3BSD, Sun).\\
\signal{SIGIO} &B & T & L'I/O è possibile.\\
\signal{SIGPOLL} &VS& T & \textit{Pollable event}, sinonimo di
\begin{table}[htb]
\footnotesize
\centering
- \begin{tabular}[c]{|r|l|}
+ \begin{tabular}[c]{|r|p{8cm}|}
\hline
\textbf{Valore} & \textbf{Significato} \\
\hline
non significa che esso sia realmente quello a cui si intendeva mandare il
segnale.
+Indipendentemente dalla funzione specifica che viene usata solo
+l'amministratore può inviare un segnale ad un processo qualunque, in tutti gli
+altri casi l'\ids{UID} reale o l'\ids{UID} effettivo del processo chiamante
+devono corrispondere all'\ids{UID} reale o all'\ids{UID} salvato della
+destinazione. Fa eccezione il caso in cui il segnale inviato sia
+\signal{SIGCONT}, nel quale occorre anche che entrambi i processi appartengano
+alla stessa sessione.
+
+Si tenga presente che, per il ruolo fondamentale che riveste nel sistema, non
+è possibile inviare al processo 1 (cioè a \cmd{init}) segnali per i quali esso
+non abbia un gestore installato. Infine, seguendo le specifiche POSIX
+1003.1-2001, l'uso della chiamata \code{kill(-1, sig)} comporta che il segnale
+sia inviato (con la solita eccezione di \cmd{init}) a tutti i processi per i
+quali i permessi lo consentano. Lo standard permette comunque alle varie
+implementazioni di escludere alcuni processi specifici: nel caso in questione
+Linux non invia il segnale al processo che ha effettuato la chiamata.
+
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
}
{ La funzione ritorna $0$ in caso di successo e $-1$ per un errore, e gli
- errori sono gli stessi di \func{kill}. }
+ errori sono gli stessi di \func{kill}.
+}
\end{funcproto}
La funzione invia il segnale \param{signal} al \itindex{process~group}
-\textit{process group} \param{pidgrp} ed è è sostanzialmente equivalente
-all'esecuzione di \code{kill(-pidgrp, signal)}.
-
-Oltre a queste funzioni di base vedremo più avanti che esistono altre funzioni
-per inviare segnali, come \func{sigqueue} per i segnali \textit{real-time}
-(vedi sez.~\ref{sec:sig_real_time}) e le specifiche funzioni per i
-\textit{thread} che tratteremo in sez.~\ref{sec:thread_signal}.
-
-Ma indipendentemente dalla funzione usata solo l'amministratore può inviare un
-segnale ad un processo qualunque, in tutti gli altri casi l'\ids{UID} reale o
-l'\ids{UID} effettivo del processo chiamante devono corrispondere
-all'\ids{UID} reale o all'\ids{UID} salvato della destinazione. Fa eccezione
-il caso in cui il segnale inviato sia \signal{SIGCONT}, nel quale occorre che
-entrambi i processi appartengano alla stessa sessione. Inoltre, dato il ruolo
-fondamentale che riveste nel sistema (si ricordi quanto visto in
-sez.~\ref{sec:sig_termination}), non è possibile inviare al processo 1 (cioè a
-\cmd{init}) segnali per i quali esso non abbia un gestore installato.
-
-Infine, seguendo le specifiche POSIX 1003.1-2001, l'uso della chiamata
-\code{kill(-1, sig)} comporta che il segnale sia inviato (con la solita
-eccezione di \cmd{init}) a tutti i processi per i quali i permessi lo
-consentano. Lo standard permette comunque alle varie implementazioni di
-escludere alcuni processi specifici: nel caso in questione Linux non invia il
-segnale al processo che ha effettuato la chiamata.
-
-
-\subsection{Le funzioni di allarme ed interruzione ed i \textit{timer}}
+\textit{process group} il cui \acr{PGID} (vedi sez.~\ref{sec:sess_proc_group})
+è indicato dall'argomento \param{pidgrp}, che deve essere un intero
+positivo. Il suo utilizzo è sostanzialmente equivalente all'esecuzione di
+\code{kill(-pidgrp, signal)}.
+
+Oltre alle precedenti funzioni di base, vedremo più avanti che esistono altre
+funzioni per inviare segnali generici, come \func{sigqueue} per i segnali
+\textit{real-time} (vedi sez.~\ref{sec:sig_real_time}) e le specifiche
+funzioni per i \textit{thread} che tratteremo in sez.~\ref{sec:thread_signal}.
+
+Esiste però un'ultima funzione che permette l'invio diretto di un segnale che
+vale la pena di trattare a parte per le sue peculiarità. La funzione in
+questione è \funcd{abort} che, come accennato in
+sez.~\ref{sec:proc_termination}, permette di abortire l'esecuzione di un
+programma tramite l'invio del segnale \signal{SIGABRT}. Il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{stdlib.h}
+\fdecl{void abort(void)}
+\fdesc{Abortisce il processo corrente.}
+}
+
+{La funzione non ritorna, il processo viene terminato.}
+\end{funcproto}
+
+La differenza fra questa funzione e l'uso di \func{raise} o di un'altra
+funzione per l'invio di \signal{SIGABRT} è che anche se il segnale è bloccato
+o ignorato, la funzione ha effetto lo stesso. Il segnale può però essere
+intercettato per effettuare eventuali operazioni di chiusura prima della
+terminazione del processo.
+
+Lo standard ANSI C richiede inoltre che anche se il gestore ritorna, la
+funzione non ritorni comunque. Lo standard POSIX.1 va oltre e richiede che se
+il processo non viene terminato direttamente dal gestore sia la stessa
+\func{abort} a farlo al ritorno dello stesso. Inoltre, sempre seguendo lo
+standard POSIX, prima della terminazione tutti i file aperti e gli stream
+saranno chiusi ed i buffer scaricati su disco. Non verranno invece eseguite le
+eventuali funzioni registrate con \func{atexit} e \func{on\_exit}.
+
+
+
+
+\subsection{Le funzioni di allarme ed i \textit{timer}}
\label{sec:sig_alarm_abort}
Un caso particolare di segnali generati a richiesta è quello che riguarda i
-vari segnali di temporizzazione e \signal{SIGABRT}, per ciascuno di questi
-segnali sono previste funzioni specifiche che ne effettuino l'invio. La più
-comune delle funzioni usate per la temporizzazione è \funcd{alarm} il cui
-prototipo è:
+vari segnali usati per la temporizzazione, per ciascuno di essi infatti sono
+previste delle funzioni specifiche che ne effettuino l'invio. La più comune, e
+la più semplice, delle funzioni usate per la temporizzazione è la funzione di
+sistema \funcd{alarm}, il cui prototipo è:
\begin{funcproto}{
\fhead{unistd.h}
\item un \textit{profiling timer} che calcola la somma dei tempi di processore
utilizzati direttamente dal processo in user space, e dal kernel nelle
\textit{system call} ad esso relative (che corrisponde a quello che in
- sez.~\ref{sec:sys_unix_time} abbiamo chiamato \textit{CPU time}). La
+ sez.~\ref{sec:sys_unix_time} abbiamo chiamato \textit{processor time}). La
scadenza di questo timer provoca l'emissione di \signal{SIGPROF}.
\end{itemize*}
che permette di usare un timer qualunque e l'invio di segnali periodici, al
costo però di una maggiore complessità d'uso e di una minore portabilità. Il
suo prototipo è:
-\begin{prototype}{sys/time.h}{int setitimer(int which, const struct
- itimerval *value, struct itimerval *ovalue)}
-
- Predispone l'invio di un segnale di allarme alla scadenza dell'intervallo
- \param{value} sul timer specificato da \param{which}.
+
+\begin{funcproto}{
+\fhead{sys/time.h}
+\fdecl{int setitimer(int which, const struct itimerval *value, struct
+ itimerval *ovalue)}
- \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori \errval{EINVAL} o
- \errval{EFAULT}.}
-\end{prototype}
+\fdesc{Predispone l'invio di un segnale di allarme.}
+}
-Il valore di \param{which} permette di specificare quale dei tre timer
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori \errval{EINVAL} o \errval{EFAULT}
+ nel loro significato generico.}
+\end{funcproto}
+
+
+La funzione predispone l'invio di un segnale di allarme alla scadenza
+dell'intervallo indicato dall'argomento \param{value}. Il valore
+dell'argomento \param{which} permette di specificare quale dei tre timer
illustrati in precedenza usare; i possibili valori sono riportati in
tab.~\ref{tab:sig_setitimer_values}.
\begin{table}[htb]
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.8\textwidth}
\includestruct{listati/itimerval.h}
\end{minipage}
\normalsize
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.8\textwidth}
\includestruct{listati/alarm_def.c}
\end{minipage}
\normalsize
\end{figure}
Si deve comunque tenere presente che fino al kernel 2.6.16 la precisione di
-queste funzioni era limitata dalla frequenza del timer di sistema,\footnote{il
- valore della costante \texttt{HZ}, di cui abbiamo già parlato in
- sez.~\ref{sec:proc_hierarchy}.} in quanto le temporizzazioni erano calcolate
-in numero di interruzioni del timer (i cosiddetti \itindex{jiffies}
+queste funzioni era limitata dalla frequenza del timer di sistema, determinato
+dal valore della costante \texttt{HZ} di cui abbiamo già parlato in
+sez.~\ref{sec:proc_hierarchy}, in quanto le temporizzazioni erano calcolate in
+numero di interruzioni del timer (i cosiddetti \itindex{jiffies}
``\textit{jiffies}''), ed era assicurato soltanto che il segnale non sarebbe
stato mai generato prima della scadenza programmata (l'arrotondamento cioè era
effettuato per eccesso).\footnote{questo in realtà non è del tutto vero a
causa di un bug, presente fino al kernel 2.6.12, che in certe circostanze
- causava l'emissione del segnale con un arrotondamento per difetto.} L'uso
-del contatore dei \itindex{jiffies} \textit{jiffies}, un intero a 32 bit,
-comportava inoltre l'impossibilità di specificare tempi molto
-lunghi.\footnote{superiori al valore della costante
- \const{MAX\_SEC\_IN\_JIFFIES}, pari, nel caso di default di un valore di
- \const{HZ} di 250, a circa 99 giorni e mezzo.} Con il cambiamento della
+ causava l'emissione del segnale con un arrotondamento per difetto.}
+
+L'uso del contatore dei \itindex{jiffies} \textit{jiffies}, un intero a 32 bit
+nella maggior parte dei casi, comportava inoltre l'impossibilità di
+specificare tempi molto lunghi. superiori al valore della costante
+\const{MAX\_SEC\_IN\_JIFFIES}, pari, nel caso di default di un valore di
+\const{HZ} di 250, a circa 99 giorni e mezzo. Con il cambiamento della
rappresentazione effettuato nel kernel 2.6.16 questo problema è scomparso e
con l'introduzione dei timer ad alta risoluzione (vedi
sez.~\ref{sec:sig_timer_adv}) nel kernel 2.6.21 la precisione è diventata
Questo ha una conseguenza che può indurre ad errori molto subdoli, si tenga
conto poi che in caso di sistema molto carico, si può avere il caso patologico
in cui un timer scade prima che il segnale di una precedente scadenza sia
-stato consegnato; in questo caso, per il comportamento dei segnali descritto
+stato consegnato. In questo caso, per il comportamento dei segnali descritto
in sez.~\ref{sec:sig_sigchld}, un solo segnale sarà consegnato. Per questo
-oggi l'uso di questa funzione è deprecato a favore dei \textit{POSIX timer}
-che tratteremo in sez.~\ref{sec:sig_timer_adv}.
+oggi l'uso di questa funzione è deprecato a favore degli
+\index{High~Resolution~Timer~(HRT)} \textit{high-resolution timer} e della
+cosiddetta \itindex{POSIX~Timer~API} \textit{POSIX Timer API}, che tratteremo
+in sez.~\ref{sec:sig_timer_adv}.
Dato che sia \func{alarm} che \func{setitimer} non consentono di leggere il
valore corrente di un timer senza modificarlo, è possibile usare la funzione
\funcd{getitimer}, il cui prototipo è:
-\begin{prototype}{sys/time.h}{int getitimer(int which, struct
- itimerval *value)}
-
- Legge in \param{value} il valore del timer specificato da \param{which}.
-
- \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore e restituisce gli stessi errori di \func{getitimer}.}
-\end{prototype}
-\noindent i cui argomenti hanno lo stesso significato e formato di quelli di
-\func{setitimer}.
+\begin{funcproto}{
+\fhead{sys/time.h}
+\fdecl{int getitimer(int which, struct itimerval *value)}
+\fdesc{Legge il valore di un timer.}
+}
-L'ultima funzione che permette l'invio diretto di un segnale è \funcd{abort},
-che, come accennato in sez.~\ref{sec:proc_termination}, permette di abortire
-l'esecuzione di un programma tramite l'invio di \signal{SIGABRT}. Il suo
-prototipo è:
-\begin{prototype}{stdlib.h}{void abort(void)}
-
- Abortisce il processo corrente.
-
- \bodydesc{La funzione non ritorna, il processo è terminato inviando il
- segnale di \signal{SIGABRT}.}
-\end{prototype}
-
-La differenza fra questa funzione e l'uso di \func{raise} è che anche se il
-segnale è bloccato o ignorato, la funzione ha effetto lo stesso. Il segnale
-può però essere intercettato per effettuare eventuali operazioni di chiusura
-prima della terminazione del processo.
+{ La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà gli stessi valori di \func{getitimer}. }
+\end{funcproto}
-Lo standard ANSI C richiede inoltre che anche se il gestore ritorna, la
-funzione non ritorni comunque. Lo standard POSIX.1 va oltre e richiede che se
-il processo non viene terminato direttamente dal gestore sia la stessa
-\func{abort} a farlo al ritorno dello stesso. Inoltre, sempre seguendo lo
-standard POSIX, prima della terminazione tutti i file aperti e gli stream
-saranno chiusi ed i buffer scaricati su disco. Non verranno invece eseguite le
-eventuali funzioni registrate con \func{atexit} e \func{on\_exit}.
+La funzione legge nella struttura \struct{itimerval} puntata da \param{value}
+il valore del timer specificato da \param{which} ed i suoi argomenti hanno lo
+stesso significato e formato di quelli di \func{setitimer}.
\subsection{Le funzioni di pausa e attesa}
Sono parecchie le occasioni in cui si può avere necessità di sospendere
temporaneamente l'esecuzione di un processo. Nei sistemi più elementari in
-genere questo veniva fatto con un opportuno loop di attesa, ma in un sistema
-multitasking un loop di attesa è solo un inutile spreco di CPU, per questo ci
-sono apposite funzioni che permettono di mettere un processo in stato di
-attesa.\footnote{si tratta in sostanza di funzioni che permettono di portare
- esplicitamente il processo in stato di \textit{sleep}, vedi
- sez.~\ref{sec:proc_sched}.}
-
-Il metodo tradizionale per fare attendere ad un processo fino all'arrivo di un
-segnale è quello di usare la funzione \funcd{pause}, il cui prototipo è:
-\begin{prototype}{unistd.h}{int pause(void)}
-
- Pone il processo in stato di sleep fino al ritorno di un gestore.
-
- \bodydesc{La funzione ritorna solo dopo che un segnale è stato ricevuto ed
- il relativo gestore è ritornato, nel qual caso restituisce $-1$ e
- \var{errno} assumerà il valore \errval{EINTR}.}
-\end{prototype}
+genere questo veniva fatto con un ciclo di attesa in cui il programma ripete
+una operazione un numero sufficiente di volte per far passare il tempo
+richiesto.
+
+Ma in un sistema multitasking un ciclo di attesa è solo un inutile spreco di
+tempo di processore, dato che altri programmi possono essere eseguiti nel
+frattempo, per questo ci sono delle apposite funzioni che permettono di
+mantenere un processo in attesa per il tempo voluto, senza impegnare il
+processore. In pratica si tratta di funzioni che permettono di portare
+esplicitamente il processo nello stato di \textit{sleep} (si ricordi quanto
+illustrato in tab.~\ref{tab:proc_proc_states}) per un certo periodo di tempo.
+
+La prima di queste è la funzione di sistema \funcd{pause}, che viene usata per
+mettere un processo in attesa per un periodo di tempo indefinito, fino
+all'arrivo di un segnale, il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int pause(void)}
+\fdesc{Pone il processo in pausa fino al ricevimento di un segnale.}
+}
+
+{La funzione ritorna solo dopo che un segnale è stato ricevuto ed il relativo
+ gestore è ritornato, nel qual caso restituisce $-1$ e \var{errno} assume il
+ valore \errval{EINTR}.}
+\end{funcproto}
-La funzione segnala sempre una condizione di errore (il successo sarebbe
-quello di aspettare indefinitamente). In genere si usa questa funzione quando
-si vuole mettere un processo in attesa di un qualche evento specifico che non
-è sotto il suo diretto controllo (ad esempio la si può usare per interrompere
-l'esecuzione del processo fino all'arrivo di un segnale inviato da un altro
-processo).
+La funzione ritorna sempre con una condizione di errore, dato che il successo
+sarebbe quello di continuare ad aspettare indefinitamente. In genere si usa
+questa funzione quando si vuole mettere un processo in attesa di un qualche
+evento specifico che non è sotto il suo diretto controllo, ad esempio la si
+può usare per interrompere l'esecuzione del processo fino all'arrivo di un
+segnale inviato da un altro processo.
Quando invece si vuole fare attendere un processo per un intervallo di tempo
-già noto nello standard POSIX.1 viene definita la funzione \funcd{sleep}, il
-cui prototipo è:
-\begin{prototype}{unistd.h}{unsigned int sleep(unsigned int seconds)}
-
- Pone il processo in stato di sleep per \param{seconds} secondi.
-
- \bodydesc{La funzione restituisce zero se l'attesa viene completata, o il
- numero di secondi restanti se viene interrotta da un segnale.}
-\end{prototype}
+già noto in partenza, lo standard POSIX.1 prevede una funzione di attesa
+specifica, \funcd{sleep}, il cui prototipo è:
-La funzione attende per il tempo specificato, a meno di non essere interrotta
-da un segnale. In questo caso non è una buona idea ripetere la chiamata per il
-tempo rimanente, in quanto la riattivazione del processo può avvenire in un
-qualunque momento, ma il valore restituito sarà sempre arrotondato al secondo,
-con la conseguenza che, se la successione dei segnali è particolarmente
-sfortunata e le differenze si accumulano, si potranno avere ritardi anche di
-parecchi secondi. In genere la scelta più sicura è quella di stabilire un
-termine per l'attesa, e ricalcolare tutte le volte il numero di secondi da
-aspettare.
-
-In alcune implementazioni inoltre l'uso di \func{sleep} può avere conflitti
-con quello di \signal{SIGALRM}, dato che la funzione può essere realizzata con
-l'uso di \func{pause} e \func{alarm} (in maniera analoga all'esempio che
-vedremo in sez.~\ref{sec:sig_example}). In tal caso mescolare chiamata di
-\func{alarm} e \func{sleep} o modificare l'azione di \signal{SIGALRM}, può
-causare risultati indefiniti. Nel caso delle \acr{glibc} è stata usata una
-implementazione completamente indipendente e questi problemi non ci sono.
+\begin{funcproto}{
+
+\fhead{unistd.h}
+\fdecl{unsigned int sleep(unsigned int seconds)}
+\fdesc{Pone il processo in pausa per un tempo in secondi.}
+}
+
+{La funzione ritorna $0$ se l'attesa viene completata o il
+ numero di secondi restanti se viene interrotta da un segnale, non sono
+ previsti codici di errore.}
+\end{funcproto}
+
+La funzione pone il processo in stato di \textit{sleep} per il numero di
+secondi specificato dall'argomento \param{seconds}, a meno di non essere
+interrotta da un segnale. Alla terminazione del periodo di tempo indicato la
+funzione ritorna riportando il processo in stato \textit{runnable} così che
+questo possa riprendere l'esecuzione.
+
+In caso di interruzione della funzione non è una buona idea ripetere la
+chiamata per il tempo rimanente restituito dalla stessa, in quanto la
+riattivazione del processo può avvenire in un qualunque momento, ma il valore
+restituito sarà sempre arrotondato al secondo. Questo può avere la conseguenza
+che se la successione dei segnali è particolarmente sfortunata e le differenze
+si accumulano, si possono avere ritardi anche di parecchi secondi rispetto a
+quanto programmato inizialmente. In genere la scelta più sicura in questo caso
+è quella di stabilire un termine per l'attesa, e ricalcolare tutte le volte il
+numero di secondi che restano da aspettare.
+
+Si tenga presente che alcune implementazioni l'uso di \func{sleep} può avere
+conflitti con quello di \signal{SIGALRM}, dato che la funzione può essere
+realizzata con l'uso di \func{pause} e \func{alarm}, in una maniera analoga a
+quella dell'esempio che vedremo in sez.~\ref{sec:sig_example}. In tal caso
+mescolare chiamate di \func{alarm} e \func{sleep} o modificare l'azione
+associata \signal{SIGALRM}, può portare a dei risultati indefiniti. Nel caso
+delle \acr{glibc} è stata usata una implementazione completamente indipendente
+e questi problemi non ci sono, ma un programma portabile non può fare questa
+assunzione.
La granularità di \func{sleep} permette di specificare attese soltanto in
-secondi, per questo sia sotto BSD4.3 che in SUSv2 è stata definita la funzione
-\funcd{usleep} (dove la \texttt{u} è intesa come sostituzione di $\mu$); i due
-standard hanno delle definizioni diverse, ma le \acr{glibc}
-seguono\footnote{secondo la pagina di manuale almeno dalla versione 2.2.2.}
-seguono quella di SUSv2 che prevede il seguente prototipo:
-\begin{prototype}{unistd.h}{int usleep(unsigned long usec)}
-
- Pone il processo in stato di sleep per \param{usec} microsecondi.
-
- \bodydesc{La funzione restituisce zero se l'attesa viene completata, o $-1$
- in caso di errore, nel qual caso \var{errno} assumerà il valore
- \errval{EINTR}.}
+secondi, per questo sia sotto BSD4.3 che in SUSv2 è stata definita un'altra
+funzione con una precisione teorica del microsecondo. I due standard hanno
+delle definizioni diverse, ma le \acr{glibc} seguono (secondo la pagina di
+manuale almeno dalla versione 2.2.2) seguono quella di SUSv2 per cui la
+funzione \funcd{usleep} (dove la \texttt{u} è intesa come sostituzione di
+$\mu$), ha il seguente prototipo:
-\end{prototype}
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int usleep(unsigned long usec)}
+\fdesc{Pone il processo in pausa per un tempo in microsecondi.}
+}
+
+{La funzione ritorna $0$ se l'attesa viene completata e $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINVAL}] si è indicato un valore di \param{usec} maggiore di
+ 1000000.
+ \end{errlist}
+}
+\end{funcproto}
Anche questa funzione, a seconda delle implementazioni, può presentare
-problemi nell'interazione con \func{alarm} e \signal{SIGALRM}. È pertanto
-deprecata in favore della funzione \funcd{nanosleep}, definita dallo standard
-POSIX1.b, il cui prototipo è:
-\begin{prototype}{unistd.h}{int nanosleep(const struct timespec *req, struct
- timespec *rem)}
-
- Pone il processo in stato di sleep per il tempo specificato da \param{req}.
- In caso di interruzione restituisce il tempo restante in \param{rem}.
-
- \bodydesc{La funzione restituisce zero se l'attesa viene completata, o $-1$
- in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
- \begin{errlist}
+problemi nell'interazione con \func{alarm} e \signal{SIGALRM}, per questo
+motivo, pur essendovi citata, nello standard POSIX.1-2001 viene deprecata in
+favore della nuova funzione di sistema \funcd{nanosleep}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int nanosleep(const struct timespec *req, struct timespec *rem)}
+\fdesc{Pone il processo in pausa per un periodo di tempo.}
+}
+
+{La funzione ritorna $0$ se l'attesa viene completata e $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
\item[\errcode{EINVAL}] si è specificato un numero di secondi negativo o un
numero di nanosecondi maggiore di 999.999.999.
\item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
- \end{errlist}}
-\end{prototype}
+ \end{errlist}
+}
+\end{funcproto}
-Lo standard richiede che la funzione sia implementata in maniera del tutto
-indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto
- utilizzando direttamente il timer del kernel.} e sia utilizzabile senza
-interferenze con l'uso di \signal{SIGALRM}. La funzione prende come argomenti
-delle strutture di tipo \struct{timespec}, la cui definizione è riportata in
-fig.~\ref{fig:sys_timespec_struct}, che permette di specificare un tempo con
-una precisione fino al nanosecondo.
+La funzione pone il processo in pausa portandolo nello stato di \textit{sleep}
+per il tempo specificato dall'argomento \param{req}, ed in caso di
+interruzione restituisce il tempo restante nell'argomento \param{rem}. Lo
+standard richiede che la funzione sia implementata in maniera del tutto
+indipendente da \func{alarm}, e nel caso di Linux questo è fatto utilizzando
+direttamente il timer del kernel. Lo standard richiede inoltre che la funzione
+sia utilizzabile senza interferenze con l'uso di \signal{SIGALRM}. La funzione
+prende come argomenti delle strutture di tipo \struct{timespec}, la cui
+definizione è riportata in fig.~\ref{fig:sys_timespec_struct}, il che permette
+di specificare un tempo con una precisione teorica fino al nanosecondo.
La funzione risolve anche il problema di proseguire l'attesa dopo
l'interruzione dovuta ad un segnale; infatti in tal caso in \param{rem} viene
2.4, in cui, per i processi riavviati dopo essere stati fermati da un
segnale, il tempo passato in stato \texttt{T} non viene considerato nel
calcolo della rimanenza.} e basta richiamare la funzione per completare
-l'attesa.\footnote{anche qui però occorre tenere presente che i tempi sono
- arrotondati, per cui la precisione, per quanto migliore di quella ottenibile
- con \func{sleep}, è relativa e in caso di molte interruzioni si può avere
- una deriva, per questo esiste la funzione \func{clock\_nanosleep} (vedi
- sez.~\ref{sec:sig_timer_adv}) che permette di specificare un tempo assoluto
- anziché un tempo relativo.}
+l'attesa.
+
+Anche qui però occorre tenere presente che i tempi sono arrotondati, per cui
+la precisione, per quanto migliore di quella ottenibile con \func{sleep}, è
+relativa e in caso di molte interruzioni si può avere una deriva, per questo
+esiste la funzione \func{clock\_nanosleep} (vedi sez.~\ref{sec:sig_timer_adv})
+che permette di specificare un tempo assoluto anziché un tempo relativo.
Chiaramente, anche se il tempo può essere specificato con risoluzioni fino al
nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
Un semplice esempio per illustrare il funzionamento di un gestore di segnale è
quello della gestione di \signal{SIGCHLD}. Abbiamo visto in
sez.~\ref{sec:proc_termination} che una delle azioni eseguite dal kernel alla
-conclusione di un processo è quella di inviare questo segnale al
-padre.\footnote{in realtà in SVr4 eredita la semantica di System V, in cui il
- segnale si chiama \signal{SIGCLD} e viene trattato in maniera speciale; in
- System V infatti se si imposta esplicitamente l'azione a \const{SIG\_IGN} il
- segnale non viene generato ed il sistema non genera \itindex{zombie}
- \textit{zombie} (lo stato di terminazione viene scartato senza dover
- chiamare una \func{wait}). L'azione predefinita è sempre quella di ignorare
- il segnale, ma non attiva questo comportamento. Linux, come BSD e POSIX, non
- supporta questa semantica ed usa il nome di \signal{SIGCLD} come sinonimo di
- \signal{SIGCHLD}.} In generale dunque, quando non interessa elaborare lo
-stato di uscita di un processo, si può completare la gestione della
-terminazione installando un gestore per \signal{SIGCHLD} il cui unico compito
-sia quello di chiamare \func{waitpid} per completare la procedura di
-terminazione in modo da evitare la formazione di \itindex{zombie}
-\textit{zombie}.
+conclusione di un processo è quella di inviare questo segnale al padre. In
+generale dunque, quando non interessa elaborare lo stato di uscita di un
+processo, si può completare la gestione della terminazione installando un
+gestore per \signal{SIGCHLD} il cui unico compito sia quello di chiamare
+\func{waitpid} per completare la procedura di terminazione in modo da evitare
+la formazione di \itindex{zombie} \textit{zombie}.\footnote{si ricordi
+ comunque che dal kernel 2.6 seguendo lo standard POSIX.1-2001 per evitare di
+ dover ricevere gli stati di uscita che non interessano basta impostare come
+ azione predefinita quella di ignorare \signal{SIGCHLD}, nel qual caso viene
+ assunta la semantica di System V, in cui il segnale non viene inviato, il
+ sistema non genera \itindex{zombie} \textit{zombie} e lo stato di
+ terminazione viene scartato senza dover chiamare una \func{wait}.}
In fig.~\ref{fig:sig_sigchld_handl} è mostrato il codice contenente una
implementazione generica di una funzione di gestione per \signal{SIGCHLD},
\label{fig:sig_sigchld_handl}
\end{figure}
-Il codice del gestore è di lettura immediata; come buona norma di
+Il codice del gestore è di lettura immediata, come buona norma di
programmazione (si ricordi quanto accennato sez.~\ref{sec:sys_errno}) si
comincia (\texttt{\small 6--7}) con il salvare lo stato corrente di
\var{errno}, in modo da poterlo ripristinare prima del ritorno del gestore
(\texttt{\small 16--17}). In questo modo si preserva il valore della variabile
visto dal corso di esecuzione principale del processo, che altrimenti sarebbe
-sovrascritto dal valore restituito nella successiva chiamata di \func{waitpid}.
+sovrascritto dal valore restituito nella successiva chiamata di
+\func{waitpid}.
Il compito principale del gestore è quello di ricevere lo stato di
terminazione del processo, cosa che viene eseguita nel ciclo in
versione di \func{sleep} potrebbe essere quella illustrata in
fig.~\ref{fig:sig_sleep_wrong}.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/sleep_danger.c}
Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
SVr2) usando la funzione \func{longjmp} (vedi sez.~\ref{sec:proc_longjmp}) per
-uscire dal gestore; in questo modo, con una condizione sullo stato di
+uscire dal gestore. In questo modo, con una condizione sullo stato di
uscita di quest'ultima, si può evitare la chiamata a \func{pause}, usando un
codice del tipo di quello riportato in fig.~\ref{fig:sig_sleep_incomplete}.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/sleep_defect.c}
\end{figure}
In questo caso il gestore (\texttt{\small 18-27}) non ritorna come in
-fig.~\ref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 25}) per
-rientrare nel corpo principale del programma; dato che in questo caso il
-valore di uscita di \func{setjmp} è 1, grazie alla condizione in
-(\texttt{\small 9-12}) si evita comunque che \func{pause} sia chiamata a
-vuoto.
-
-Ma anche questa implementazione comporta dei problemi; in questo caso infatti
-non viene gestita correttamente l'interazione con gli altri segnali; se
+fig.~\ref{fig:sig_sleep_wrong}, ma usa la funzione \func{longjmp}
+(\texttt{\small 25}) per rientrare direttamente nel corpo principale del
+programma. Dato che in questo caso il valore di uscita che verrà restituito da
+\func{setjmp} è 1, grazie alla condizione impostata in (\texttt{\small 9-12})
+si potrà evitare comunque che \func{pause} sia chiamata a vuoto.
+
+Ma anche questa implementazione comporta dei problemi, in questo caso infatti
+non viene gestita correttamente l'interazione con gli altri segnali. Se
infatti il segnale di allarme interrompe un altro gestore, l'esecuzione non
riprenderà nel gestore in questione, ma nel ciclo principale, interrompendone
inopportunamente l'esecuzione. Lo stesso tipo di problemi si presenterebbero
-se si volesse usare \func{alarm} per stabilire un timeout su una qualunque
-\textit{system call} bloccante.
-
-Un secondo esempio è quello in cui si usa il segnale per notificare una
-qualche forma di evento; in genere quello che si fa in questo caso è impostare
-nel gestore un opportuno flag da controllare nel corpo principale del
-programma (con un codice del tipo di quello riportato in
-fig.~\ref{fig:sig_event_wrong}). La logica è quella di far impostare al
-gestore (\texttt{\small 14-19}) una \index{variabili!globali} variabile
-globale preventivamente inizializzata nel programma principale, il quale potrà
-determinare, osservandone il contenuto, l'occorrenza o meno del segnale, e
-prendere le relative azioni conseguenti (\texttt{\small 6-11}).
+se si volesse usare questa implementazione di \func{alarm} per stabilire un
+timeout su una qualunque \textit{system call} bloccante.
+
+Un secondo esempio dei problemi a cui si può andare incontro è quello in cui
+si usa un segnale per notificare una qualche forma di evento. In genere quello
+che si fa in questo caso è impostare all'interno del gestore un opportuno flag
+da controllare nel corpo principale del programma, con un codice del tipo di
+quello riportato in fig.~\ref{fig:sig_event_wrong}.
+
+La logica del programma è quella di far impostare al gestore (\texttt{\small
+ 14-19}) una \index{variabili!globali} variabile globale, preventivamente
+inizializzata nel programma principale, ad un diverso valore. In questo modo
+dal corpo principale del programma si potrà determinare, osservandone il
+contenuto di detta variabile, l'occorrenza o meno del segnale, ed eseguire le
+azioni conseguenti (\texttt{\small 6-11}) relative.
\begin{figure}[!htbp]
\footnotesize\centering
Questo è il tipico esempio di caso, già citato in
sez.~\ref{sec:proc_race_cond}, in cui si genera una \itindex{race~condition}
-\textit{race condition}; infatti, in una situazione in cui un segnale è già
-arrivato (e \var{flag} è già ad 1) se un altro segnale arriva immediatamente
-dopo l'esecuzione del controllo (\texttt{\small 6}) ma prima della
-cancellazione del flag (\texttt{\small 7}), la sua occorrenza sarà perduta.
+\textit{race condition}. Infatti, in una situazione in cui un segnale è già
+arrivato (e quindi \var{flag} è già stata impostata ad 1 nel gestre) se un
+altro segnale arriva immediatamente dopo l'esecuzione del controllo
+(\texttt{\small 6}) ma prima della cancellazione di \var{flag} fatta subito
+dopo (\texttt{\small 7}), la sua occorrenza sarà perduta.
-Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono
-delle funzioni più sofisticate di quelle finora illustrate, queste hanno la
-loro origine nella semplice interfaccia dei primi sistemi Unix, ma con esse
-non è possibile gestire in maniera adeguata di tutti i possibili aspetti con
-cui un processo deve reagire alla ricezione di un segnale.
+Questi esempi ci mostrano come per poter eseguire una gestione effettiva dei
+segnali occorrono delle funzioni più sofisticate di quelle finora
+illustrate. La fuzione \func{signal} infatti ha la sua origine nella
+interfaccia alquanto primitiva che venne adottata nei primi sistemi Unix, ma
+con questa funzione è sostanzilmente impossibile gestire in maniera adeguata
+di tutti i possibili aspetti con cui un processo deve reagire alla ricezione
+di un segnale.
originarie, nate con la semantica inaffidabile, hanno dei limiti non
superabili; in particolare non è prevista nessuna funzione che permetta di
gestire il blocco dei segnali o di verificare lo stato dei segnali pendenti.
+
Per questo motivo lo standard POSIX.1, insieme alla nuova semantica dei
segnali ha introdotto una interfaccia di gestione completamente nuova, che
permette di ottenere un controllo molto più dettagliato. In particolare lo
viene usualmente chiamato), tale tipo di dato viene usato per gestire il
blocco dei segnali.
-In genere un \textsl{insieme di segnali} è rappresentato da un intero di
-dimensione opportuna, di solito pari al numero di bit dell'architettura della
-macchina,\footnote{nel caso dei PC questo comporta un massimo di 32 segnali
- distinti: dato che in Linux questi sono sufficienti non c'è necessità di
- nessuna struttura più complicata.} ciascun bit del quale è associato ad uno
-specifico segnale; in questo modo è di solito possibile implementare le
-operazioni direttamente con istruzioni elementari del processore. Lo standard
-POSIX.1 definisce cinque funzioni per la manipolazione degli insiemi di
-segnali: \funcd{sigemptyset}, \funcd{sigfillset}, \funcd{sigaddset},
-\funcd{sigdelset} e \funcd{sigismember}, i cui prototipi sono:
-\begin{functions}
- \headdecl{signal.h}
-
- \funcdecl{int sigemptyset(sigset\_t *set)} Inizializza un insieme di segnali
- vuoto (in cui non c'è nessun segnale).
-
- \funcdecl{int sigfillset(sigset\_t *set)} Inizializza un insieme di segnali
- pieno (in cui ci sono tutti i segnali).
-
- \funcdecl{int sigaddset(sigset\_t *set, int signum)} Aggiunge il segnale
- \param{signum} all'insieme di segnali \param{set}.
+Inizialmente un \textsl{insieme di segnali} veniva rappresentato da un intero
+di dimensione opportuna, di solito pari al numero di bit dell'architettura
+della macchina, ciascun bit del quale era associato ad uno specifico
+segnale. Nel caso di architetture a 32 bit questo comporta un massimo di 32
+segnali distinti e dato che a lungo questi sono stati sufficienti non c'era
+necessità di nessuna struttura più complicata, in questo modo era possibile
+implementare le operazioni direttamente con istruzioni elementari del
+processore.
+
+Oggi questo non è più vero, in particolare con l'introduzione dei segnali
+\textit{real-rime} (che vedremo in sez.~\ref{sec:sig_real_time}). Dato che in
+generale non si può fare conto sulle caratteristiche di una implementazione,
+perché non è detto che si disponga di un numero di bit sufficienti per mettere
+tutti i segnali in un intero, o perché in \type{sigset\_t} possono essere
+immagazzinate ulteriori informazioni, tutte le operazioni devono essere
+effettuate tramite le opportune funzioni di libreria che si curano di
+mascherare i dettagli di basso livello.
+
+Lo standard POSIX.1 definisce cinque funzioni per la manipolazione degli
+insiemi di segnali. Le prime quattro, che consentono di manipolare i contenuti
+di un \textit{signal set}, sono \funcd{sigemptyset}, \funcd{sigfillset},
+\funcd{sigaddset} e \funcd{sigdelset}; i rispettivi prototipi sono:
- \funcdecl{int sigdelset(sigset\_t *set, int signum)} Toglie il segnale
- \param{signum} dall'insieme di segnali \param{set}.
-
- \funcdecl{int sigismember(const sigset\_t *set, int signum)} Controlla se il
- segnale \param{signum} è nell'insieme di segnali \param{set}.
-
- \bodydesc{Le prime quattro funzioni ritornano 0 in caso di successo, mentre
- \func{sigismember} ritorna 1 se \param{signum} è in \param{set} e 0
- altrimenti. In caso di errore tutte ritornano $-1$, con \var{errno}
- impostata a \errval{EINVAL} (il solo errore possibile è che \param{signum}
- non sia un segnale valido).}
-\end{functions}
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigemptyset(sigset\_t *set)}
+\fdesc{Inizializza un insieme di segnali vuoto.}
+\fdecl{int sigfillset(sigset\_t *set)}
+\fdesc{Inizializza un insieme di segnali pieno.}
+\fdecl{int sigaddset(sigset\_t *set, int signum)}
+\fdesc{Aggiunge un segnale ad un insieme di segnali.}
+\fdecl{int sigdelset(sigset\_t *set, int signum)}
+\fdesc{Rimuove un segnale da un insieme di segnali.}
+}
+
+{Le funzioni ritornano $0$ in caso di successo, e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà il valore:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] \param{signum} non è un segnale valido.
+ \end{errlist}
+}
+\end{funcproto}
+
+Le prime due funzioni inizializzano l'insieme di segnali indicato
+dall'argomento \param{set} rispettivamente ad un contenuto vuoto (in cui cioè
+non c'è nessun segnale) e pieno (in cui cioè ci sono tutti i segnali). Le
+altre due funzioni consentono di inserire o rimuovere uno specifico segnale
+indicato con l'argomento \param{signum} in un insieme.
+
+A queste funzioni si aggiunge l'ulteriore \funcd{sigismember}, che consente di
+verificare la presenza di un segnale in un insieme, il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigismember(const sigset\_t *set, int signum)}
+\fdesc{Controlla se un segnale è in un insieme di segnali.}
+}
+
+{La funzione ritorna $1$ il segnale è nell'insieme e $0$ altrimenti, e $-1$
+ per un errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}
+ se si è specificato un puntatore \var{NULL}.}
+\end{funcproto}
+
+La \acr{glibc} prevede inoltre altre funzioni non standardizzate, accessibili
+definendo la macro \macro{\_GNU\_SOURCE}. La prima di queste è
+\funcd{sigisemptyset}, che consente di verificare un insieme è vuoto, il suo
+prototipo è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigisemptyset(sigset\_t *set)}
+\fdesc{Controlla se un insieme di segnali è vuoto.}
+}
+
+{La funzione ritorna $1$ l'insieme è vuoto e $0$ altrimenti, non sono previste
+ condizioni di errore.}
+\end{funcproto}
+
+Alla precedente si aggiungono altre due funzioni consentono di effettuare
+delle operazioni logiche con gli insiemi di segnali, esse sono
+\funcd{sigorset} e \funcd{sigandset}, ed i rispettivi prototipi sono:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{sigorset(sigset\_t *dest, sigset\_t *left, sigset\_t *right)}
+\fdesc{Crea l'unione di due insieme di segnali.}
+\fdecl{sigandset(sigset\_t *dest, sigset\_t *left, sigset\_t *right)}
+\fdesc{Crea l'intersezione di due insieme di segnali.}
+}
+
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà il valore \errcode{EINVAL}.}
+\end{funcproto}
-Dato che in generale non si può fare conto sulle caratteristiche di una
-implementazione (non è detto che si disponga di un numero di bit sufficienti
-per mettere tutti i segnali in un intero, o in \type{sigset\_t} possono essere
-immagazzinate ulteriori informazioni) tutte le operazioni devono essere
-comunque eseguite attraverso queste funzioni.
In genere si usa un insieme di segnali per specificare quali segnali si vuole
bloccare, o per riottenere dalle varie funzioni di gestione la maschera dei
-segnali attivi (vedi sez.~\ref{sec:sig_sigmask}). Essi possono essere definiti
-in due diverse maniere, aggiungendo i segnali voluti ad un insieme vuoto
-ottenuto con \func{sigemptyset} o togliendo quelli che non servono da un
-insieme completo ottenuto con \func{sigfillset}. Infine \func{sigismember}
-permette di verificare la presenza di uno specifico segnale in un
-insieme.
+segnali attivi (vedi sez.~\ref{sec:sig_sigmask}). La modalità più comune, che
+è anche quella più portabile, prevede che possano essere definiti aggiungendo
+i segnali voluti ad un insieme vuoto ottenuto con \func{sigemptyset} o
+togliendo quelli che non servono da un insieme completo ottenuto con
+\func{sigfillset}.
\itindend{signal~set}
POSIX.1 ha ridefinito completamente l'interfaccia per la gestione dei segnali,
rendendola molto più flessibile e robusta, anche se leggermente più complessa.
-La funzione principale dell'interfaccia POSIX.1 per i segnali è
-\funcd{sigaction}. Essa ha sostanzialmente lo stesso uso di \func{signal},
-permette cioè di specificare le modalità con cui un segnale può essere gestito
-da un processo. Il suo prototipo è:
-\begin{prototype}{signal.h}{int sigaction(int signum, const struct sigaction
- *act, struct sigaction *oldact)}
-
- Installa una nuova azione per il segnale \param{signum}.
-
- \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
- errore, nel qual caso \var{errno} assumerà i valori:
+La funzione di sistema principale prevista dall'interfaccia POSIX.1 per i
+segnali è \funcd{sigaction}. Essa ha sostanzialmente lo stesso uso di
+\func{signal}, permette cioè di specificare le modalità con cui un segnale può
+essere gestito da un processo. Il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigaction(int signum, const struct sigaction *act, struct sigaction
+ *oldact)}
+\fdesc{Installa una nuova azione pr un segnale.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINVAL}] si è specificato un numero di segnale invalido o si è
cercato di installare il gestore per \signal{SIGKILL} o
\signal{SIGSTOP}.
\item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
- \end{errlist}}
-\end{prototype}
+ \end{errlist}
+}
+\end{funcproto}
La funzione serve ad installare una nuova \textsl{azione} per il segnale
-\param{signum}; si parla di \textsl{azione} e non di \textsl{gestore}
-come nel caso di \func{signal}, in quanto la funzione consente di specificare
-le varie caratteristiche della risposta al segnale, non solo la funzione che
-verrà eseguita alla sua occorrenza. Per questo lo standard raccomanda di
-usare sempre questa funzione al posto di \func{signal} (che in genere viene
-definita tramite essa), in quanto permette un controllo completo su tutti gli
-aspetti della gestione di un segnale, sia pure al prezzo di una maggiore
-complessità d'uso.
+indicato dall'argomento \param{signum}. Si parla di \textsl{azione} e non di
+\textsl{gestore} come nel caso di \func{signal}, in quanto la funzione
+consente di specificare le varie caratteristiche della risposta al segnale,
+non solo la funzione che verrà eseguita alla sua occorrenza.
+
+Per questo motivo lo standard POSIX.1 raccomanda di usare sempre questa
+funzione al posto della precedente \func{signal}, che in genere viene
+ridefinita in termini di \func{sigaction}, in quanto la nuova interfaccia
+permette un controllo completo su tutti gli aspetti della gestione di un
+segnale, sia pure al prezzo di una maggiore complessità d'uso.
Se il puntatore \param{act} non è nullo, la funzione installa la nuova azione
da esso specificata, se \param{oldact} non è nullo il valore dell'azione
corrente viene restituito indietro. Questo permette (specificando \param{act}
nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
-che non consente di ottenere l'azione corrente senza installarne una nuova.
+che non consente di ottenere l'azione corrente senza installarne una nuova. Se
+sia \param{act} che \param{oldact} la funzione può essere utilizzata per
+verificare, se da luogo ad un errore, se il segnale indicato è valido per la
+piattaforma che si sta usando.
Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
tramite la quale si specificano tutte le caratteristiche dell'azione associata
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.8\textwidth}
\includestruct{listati/sigaction.h}
\end{minipage}
\normalsize
dell'implementazione di \code{sleep} mostrata in
fig.~\ref{fig:sig_sleep_incomplete}. In quel caso infatti se il segnale di
allarme avesse interrotto un altro gestore questo non sarebbe stato eseguito
-correttamente; la cosa poteva essere prevenuta installando gli altri gestori
-usando \var{sa\_mask} per bloccare \signal{SIGALRM} durante la loro esecuzione.
-Il valore di \var{sa\_flag} permette di specificare vari aspetti del
-comportamento di \func{sigaction}, e della reazione del processo ai vari
+correttamente, la cosa poteva essere prevenuta installando gli altri gestori
+usando \var{sa\_mask} per bloccare \signal{SIGALRM} durante la loro
+esecuzione. Il valore di \var{sa\_flag} permette di specificare vari aspetti
+del comportamento di \func{sigaction}, e della reazione del processo ai vari
segnali; i valori possibili ed il relativo significato sono riportati in
tab.~\ref{tab:sig_sa_flag}.
-\begin{table}[htb]
+\begin{table}[!htb]
\footnotesize
\centering
\begin{tabular}[c]{|l|p{8cm}|}
essere notificato quando il processo figlio viene
fermato da uno dei segnali \signal{SIGSTOP},
\signal{SIGTSTP}, \signal{SIGTTIN} o
- \signal{SIGTTOU}.\\
- \const{SA\_RESETHAND}& Ristabilisce l'azione per il segnale al valore
- predefinito una volta che il gestore è stato
- lanciato, riproduce cioè il comportamento della
- semantica inaffidabile.\\
- \const{SA\_ONESHOT} & Nome obsoleto, sinonimo non standard di
- \const{SA\_RESETHAND}; da evitare.\\
+ \signal{SIGTTOU}, questo flag ha significato solo
+ quando si imposta un gestore per \signal{SIGCHLD}.\\
+ \const{SA\_NOCLDWAIT}& Se il segnale è \signal{SIGCHLD} e si richiede di
+ ignorare il segnale con \const{SIG\_IGN} allora i
+ processi figli non diventano \itindex{zombie}
+ \textit{zombie} quando terminano; questa
+ funzionalità è stata introdotta nel kernel 2.6 e va
+ a modificare il comportamento di \func{waitpid}
+ come illustrato in sez.~\ref{sec:proc_wait}, se si
+ installa un gestore con questo flag attivo il
+ segnale \signal{SIGCHLD} viene comunque generato.\\
+ \const{SA\_NODEFER} & Evita che il segnale corrente sia bloccato durante
+ l'esecuzione del gestore.\\
+ \const{SA\_NOMASK} & Nome obsoleto e sinonimo non standard di
+ \const{SA\_NODEFER}, non deve essere più
+ utilizzato.\\
+ \const{SA\_ONESHOT} & Nome obsoleto e sinonimo non standard di
+ \const{SA\_RESETHAND}, non deve essere più
+ utilizzato.\\
\const{SA\_ONSTACK} & Stabilisce l'uso di uno \itindex{stack}
\textit{stack} alternativo per l'esecuzione del
gestore (vedi
sez.~\ref{sec:sig_specific_features}).\\
+ \const{SA\_RESETHAND}& Ristabilisce l'azione per il segnale al valore
+ predefinito una volta che il gestore è stato
+ lanciato, riproduce cioè il comportamento della
+ semantica inaffidabile.\\
\const{SA\_RESTART} & Riavvia automaticamente le \textit{slow system
call} quando vengono interrotte dal suddetto
- segnale; riproduce cioè il comportamento standard
+ segnale, riproduce cioè il comportamento standard
di BSD.\index{system~call~lente}\\
- \const{SA\_NODEFER} & Evita che il segnale corrente sia bloccato durante
- l'esecuzione del gestore.\\
- \const{SA\_NOMASK} & Nome obsoleto, sinonimo non standard di
- \const{SA\_NODEFER}.\\
\const{SA\_SIGINFO} & Deve essere specificato quando si vuole usare un
gestore in forma estesa usando
\var{sa\_sigaction} al posto di
\var{sa\_handler}.\\
- \const{SA\_NOCLDWAIT}& Se il segnale è \signal{SIGCHLD} allora i processi
- figli non diventano \itindex{zombie}
- \textit{zombie} quando terminano.\footnotemark \\
\hline
\end{tabular}
\caption{Valori del campo \var{sa\_flag} della struttura \struct{sigaction}.}
\label{tab:sig_sa_flag}
\end{table}
-\footnotetext{questa funzionalità è stata introdotta nel kernel 2.6 e va a
- modificare il comportamento di \func{waitpid}.}
-
Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette
di utilizzare due forme diverse di gestore,\footnote{la possibilità è prevista
dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x
informazioni addizionali usando \var{sa\_handler} con un secondo parametro
addizionale di tipo \var{sigcontext}, che adesso è deprecato.} 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 campi devono essere usati in maniera
- alternativa, in certe implementazioni questi campi vengono addirittura
- definiti come \direct{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 fig.~\ref{fig:sig_siginfo_t}.
+rispettivamente attraverso i campi \var{sa\_sigaction} o \var{sa\_handler}.
+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 fig.~\ref{fig:sig_siginfo_t}. I due campi devono essere usati in
+maniera alternativa, in certe implementazioni questi campi vengono addirittura
+definiti come una \direct{union}.
Installando un gestore di tipo \var{sa\_sigaction} diventa allora possibile
accedere alle informazioni restituite attraverso il puntatore a questa
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.9\textwidth}
\includestruct{listati/siginfo_t.h}
\end{minipage}
\normalsize
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{SI\_USER} & Generato da \func{kill} o \func{raise}.\\
- \const{SI\_KERNEL} & Inviato dal kernel.\\
+ \const{SI\_USER} & Generato da \func{kill} o \func{raise} o affini.\\
+ \const{SI\_KERNEL} & Inviato direttamente dal kernel.\\
\const{SI\_QUEUE} & Inviato con \func{sigqueue} (vedi
sez.~\ref{sec:sig_real_time}).\\
- \const{SI\_TIMER} & Scadenza di un POSIX timer
- (vedi sez.~\ref{sec:sig_timer_adv}).\\
+ \const{SI\_TIMER} & Scadenza di un\itindex{POSIX~Timer~API} \textit{POSIX
+ timer} (vedi sez.~\ref{sec:sig_timer_adv}).\\
\const{SI\_MESGQ} & Inviato al cambiamento di stato di una coda di
- messaggi POSIX (vedi
- sez.~\ref{sec:ipc_posix_mq}).\footnotemark\\
+ messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}),
+ introdotto con il kernel 2.6.6.\\
\const{SI\_ASYNCIO}& Una operazione di I/O asincrono (vedi
sez.~\ref{sec:file_asyncronous_io}) è stata
completata.\\
\const{SI\_SIGIO} & Segnale di \signal{SIGIO} da una coda (vedi
sez.~\ref{sec:file_asyncronous_operation}).\\
\const{SI\_TKILL} & Inviato da \func{tkill} o \func{tgkill} (vedi
- sez.~\ref{cha:threads_xxx}).\footnotemark\\
+ sez.~\ref{cha:threads_xxx}), introdotto con il kernel
+ 2.4.19.\\
\hline
\end{tabular}
\caption{Valori del campo \var{si\_code} della struttura \struct{sigaction}
\label{tab:sig_si_code_generic}
\end{table}
-\footnotetext[24]{introdotto con il kernel 2.6.6.}
-\footnotetext{introdotto con il kernel 2.4.19.}
In questo caso il valore del campo \var{si\_code} deve essere verificato nei
-confronti delle diverse costanti previste per ciascuno di detti
-segnali;\footnote{dato che si tratta di una costante, e non di una maschera
- binaria, i valori numerici vengono riutilizzati e ciascuno di essi avrà un
- significato diverso a seconda del segnale a cui è associato.} l'elenco
-dettagliato dei nomi di queste costanti è riportato nelle diverse sezioni di
-tab.~\ref{tab:sig_si_code_special} che sono state ordinate nella sequenza in
-cui si sono appena citati i rispettivi segnali.\footnote{il prefisso del nome
- indica comunque in maniera diretta il segnale a cui le costanti fanno
- riferimento.}
+confronti delle diverse costanti previste per ciascuno di detti segnali; dato
+che si tratta di costanti, e non di una maschera binaria, i valori numerici
+vengono riutilizzati e ciascuno di essi avrà un significato diverso a seconda
+del segnale a cui è associato.
+
+L'elenco dettagliato dei nomi di queste costanti è riportato nelle diverse
+sezioni di tab.~\ref{tab:sig_si_code_special} che sono state ordinate nella
+sequenza in cui si sono appena citati i rispettivi segnali, il prefisso del
+nome indica comunque in maniera diretta il segnale a cui le costanti fanno
+riferimento.
\begin{table}[!htb]
\footnotesize
\label{tab:sig_si_code_special}
\end{table}
-Il resto della struttura \struct{siginfo\_t} è definito come \direct{union} ed i
-valori eventualmente presenti dipendono dal segnale, così \signal{SIGCHLD} ed i
-segnali \textit{real-time} (vedi sez.~\ref{sec:sig_real_time}) inviati tramite
-\func{kill} avvalorano \var{si\_pid} e \var{si\_uid} coi valori corrispondenti
-al processo che ha emesso il segnale, \signal{SIGCHLD} avvalora anche i campi
-\var{si\_status}, \var{si\_utime} e \var{si\_stime} che indicano
-rispettivamente lo stato di uscita, l'\textit{user time} e il \textit{system
- time} (vedi sez.~\ref{sec:sys_cpu_times}) usati dal processo;
-\signal{SIGILL}, \signal{SIGFPE}, \signal{SIGSEGV} e \signal{SIGBUS} avvalorano
-\var{si\_addr} con l'indirizzo in cui è avvenuto l'errore, \signal{SIGIO} (vedi
+Il resto della struttura \struct{siginfo\_t} è definito come una
+\direct{union} ed i valori eventualmente presenti dipendono dal segnale
+ricevuto, così \signal{SIGCHLD} ed i segnali \textit{real-time} (vedi
+sez.~\ref{sec:sig_real_time}) inviati tramite \func{kill} avvalorano
+\var{si\_pid} e \var{si\_uid} coi valori corrispondenti al processo che ha
+emesso il segnale, \signal{SIGCHLD} avvalora anche i campi \var{si\_status},
+\var{si\_utime} e \var{si\_stime} che indicano rispettivamente lo stato di
+uscita, l'\textit{user time} e il \textit{system time} (vedi
+sez.~\ref{sec:sys_cpu_times}) usati dal processo; \signal{SIGILL},
+\signal{SIGFPE}, \signal{SIGSEGV} e \signal{SIGBUS} avvalorano \var{si\_addr}
+con l'indirizzo in cui è avvenuto l'errore, \signal{SIGIO} (vedi
sez.~\ref{sec:file_asyncronous_io}) avvalora \var{si\_fd} con il numero del
file descriptor e \var{si\_band} per i \itindex{out-of-band} dati urgenti
(vedi sez.~\ref{sec:TCP_urgent_data}) su un socket, il segnale inviato alla
-scadenza di un timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}) avvalora i
-campi \var{si\_timerid} e \var{si\_overrun}.
+scadenza di un \itindex{POSIX~Timer~API} POSIX timer (vedi
+sez.~\ref{sec:sig_timer_adv}) avvalora i campi \var{si\_timerid} e
+\var{si\_overrun}.
Benché sia possibile usare nello stesso programma sia \func{sigaction} che
\func{signal} occorre molta attenzione, in quanto le due funzioni possono
che abbia le stesse caratteristiche di \func{signal}, a definire attraverso
\func{sigaction} una funzione equivalente \func{Signal}, il cui codice è
riportato in fig.~\ref{fig:sig_Signal_code} (il codice completo si trova nel
-file \file{SigHand.c} nei sorgenti allegati). Si noti come, essendo la
-funzione estremamente semplice, essa è definita come
-\direct{inline};\footnote{la direttiva \direct{inline} viene usata per dire al
- compilatore di trattare la funzione cui essa fa riferimento in maniera
- speciale inserendo il codice direttamente nel testo del programma. Anche se
- i compilatori più moderni sono in grado di effettuare da soli queste
- manipolazioni (impostando le opportune ottimizzazioni) questa è una tecnica
- usata per migliorare le prestazioni per le funzioni piccole ed usate di
- frequente (in particolare nel kernel, dove in certi casi le ottimizzazioni
- dal compilatore, tarate per l'uso in user space, non sono sempre adatte). In
- tal caso infatti le istruzioni per creare un nuovo frame nello
- \itindex{stack} \textit{stack} per chiamare la funzione costituirebbero una
- parte rilevante del codice, appesantendo inutilmente il programma.
- Originariamente questo comportamento veniva ottenuto con delle macro, ma
- queste hanno tutta una serie di problemi di sintassi nel passaggio degli
- argomenti (si veda ad esempio \cite{PratC}) che in questo modo possono
- essere evitati.} per semplificare ulteriormente la definizione si è poi
-definito un apposito tipo \texttt{SigFunc}.
+file \file{SigHand.c} nei sorgenti allegati). Anche in questo caso, per
+semplificare la definizione si è poi definito un apposito tipo
+\texttt{SigFunc} per esprimere in forma più comprensibile la forma di un
+gestore di segnale.
+
+Si noti come, essendo la funzione estremamente semplice, essa è definita come
+\direct{inline}. Questa direttiva viene usata per dire al compilatore di
+trattare la funzione cui essa fa riferimento in maniera speciale inserendo il
+codice direttamente nel testo del programma. Anche se i compilatori più
+moderni sono in grado di effettuare da soli queste manipolazioni (impostando
+le opportune ottimizzazioni) questa è una tecnica usata per migliorare le
+prestazioni per le funzioni piccole ed usate di frequente (in particolare nel
+kernel, dove in certi casi le ottimizzazioni dal compilatore, tarate per l'uso
+in user space, non sono sempre adatte).
+
+In tal caso infatti le istruzioni per creare un nuovo frame nello
+\itindex{stack} \textit{stack} per chiamare la funzione costituirebbero una
+parte rilevante del codice, appesantendo inutilmente il programma.
+Originariamente questo comportamento veniva ottenuto con delle macro, ma
+queste hanno tutta una serie di problemi di sintassi nel passaggio degli
+argomenti (si veda ad esempio \cite{PratC}) che in questo modo possono essere
+evitati.
\textit{signal mask}}
\label{sec:sig_sigmask}
-\itindbeg{signal~mask}
+\index{maschera dei segnali|(}
Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like
permettono di bloccare temporaneamente (o di eliminare completamente,
impostando \const{SIG\_IGN} come azione) la consegna dei segnali ad un
processo. Questo è fatto specificando la cosiddetta \textsl{maschera dei
segnali} (o \textit{signal mask}) del processo\footnote{nel caso di Linux
essa è mantenuta dal campo \var{blocked} della \struct{task\_struct} del
- processo.} cioè l'insieme dei segnali la cui consegna è bloccata. Abbiamo
-accennato in sez.~\ref{sec:proc_fork} che la \textit{signal mask} viene
-ereditata dal padre alla creazione di un processo figlio, e abbiamo visto al
-paragrafo precedente che essa può essere modificata, durante l'esecuzione di
-un gestore, attraverso l'uso dal campo \var{sa\_mask} di \struct{sigaction}.
+ processo.} cioè l'insieme dei segnali la cui consegna è bloccata.
+
+Abbiamo accennato in sez.~\ref{sec:proc_fork} che la maschera dei segnali
+viene ereditata dal padre alla creazione di un processo figlio, e abbiamo
+visto al paragrafo precedente che essa può essere modificata durante
+l'esecuzione di un gestore ed automaticamente ripristinata quando questo
+ritorna, attraverso l'uso dal campo \var{sa\_mask} di \struct{sigaction}.
Uno dei problemi evidenziatisi con l'esempio di fig.~\ref{fig:sig_event_wrong}
-è che in molti casi è necessario proteggere delle sezioni di codice (nel caso
-in questione la sezione fra il controllo e la eventuale cancellazione del flag
-che testimoniava l'avvenuta occorrenza del segnale) in modo da essere sicuri
-che essi siano eseguite senza interruzioni.
-
-Le operazioni più semplici, come l'assegnazione o il controllo di una
-variabile (per essere sicuri si può usare il tipo \type{sig\_atomic\_t}) di
-norma sono atomiche; quando si devono eseguire operazioni più complesse si può
-invece usare la funzione \funcd{sigprocmask} che permette di bloccare uno o
-più segnali; il suo prototipo è:
-\begin{prototype}{signal.h}
-{int sigprocmask(int how, const sigset\_t *set, sigset\_t *oldset)}
-
- Cambia la \textsl{maschera dei segnali} del processo corrente.
-
- \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
- errore, nel qual caso \var{errno} assumerà i valori:
+è che in molti casi è necessario proteggere delle sezioni di codice, in modo
+da essere sicuri che essi siano eseguite senza interruzioni da parte di un
+segnale. Nel caso in questione si trattava della sezione di codice fra il
+controllo e la eventuale cancellazione del flag impostato dal gestore di un
+segnale che testimoniava l'avvenuta occorrenza dello stesso.
+
+Come illustrato in sez.~\ref{sec:proc_atom_oper} le operazioni più semplici,
+come l'assegnazione o il controllo di una variabile, di norma sono atomiche, e
+qualora si voglia essere sicuri si può usare il tipo \type{sig\_atomic\_t}. Ma
+quando si devono eseguire più operazioni su delle variabili (nell'esempio
+citato un controllo ed una assegnazione) o comunque eseguire una serie di
+istruzioni, l'atomicità non è più possibile.
+
+In questo caso, se si vuole essere sicuri di non poter essere interrotti da un
+segnale durante l'esecuzione di una sezione di codice, lo si può bloccare
+esplicitamente modificando la maschera dei segnali del processo con la
+funzione di sistema \funcd{sigprocmask}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigprocmask(int how, const sigset\_t *set, sigset\_t *oldset)}
+\fdesc{Imposta la maschera dei segnali del processo corrente.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
\item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
- \end{errlist}}
-\end{prototype}
+ \end{errlist}
+}
+\end{funcproto}
-La funzione usa l'insieme di segnali dato all'indirizzo \param{set} per
-modificare la maschera dei segnali del processo corrente. La modifica viene
-effettuata a seconda del valore dell'argomento \param{how}, secondo le modalità
-specificate in tab.~\ref{tab:sig_procmask_how}. Qualora si specifichi un valore
-non nullo per \param{oldset} la maschera dei segnali corrente viene salvata a
+La funzione usa l'insieme di segnali posto all'indirizzo passanto
+nell'argomento \param{set} per modificare la maschera dei segnali del processo
+corrente. La modifica viene effettuata a seconda del valore
+dell'argomento \param{how}, secondo le modalità specificate in
+tab.~\ref{tab:sig_procmask_how}. Qualora si specifichi un valore non nullo
+per \param{oldset} la maschera dei segnali corrente viene salvata a
quell'indirizzo.
\begin{table}[htb]
l'insieme di segnali voluto per poi riabilitarli alla fine della
\index{sezione~critica} sezione critica. La funzione permette di risolvere
problemi come quelli mostrati in fig.~\ref{fig:sig_event_wrong}, proteggendo
-la sezione fra il controllo del flag e la sua cancellazione.
-
-La funzione può essere usata anche all'interno di un gestore, ad esempio
-per riabilitare la consegna del segnale che l'ha invocato, in questo caso però
-occorre ricordare che qualunque modifica alla maschera dei segnali viene
-perduta alla conclusione del terminatore.
+la sezione fra il controllo del flag e la sua cancellazione. La funzione può
+essere usata anche all'interno di un gestore, ad esempio per riabilitare la
+consegna del segnale che l'ha invocato, in questo caso però occorre ricordare
+che qualunque modifica alla maschera dei segnali viene perduta al ritorno
+dallo stesso.
Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
dei casi di \itindex{race~condition} \textit{race condition} restano aperte
-alcune possibilità legate all'uso di \func{pause}; il caso è simile a quello
+alcune possibilità legate all'uso di \func{pause}. Il caso è simile a quello
del problema illustrato nell'esempio di fig.~\ref{fig:sig_sleep_incomplete}, e
cioè la possibilità che il processo riceva il segnale che si intende usare per
uscire dallo stato di attesa invocato con \func{pause} immediatamente prima
dell'esecuzione di quest'ultima. Per poter effettuare atomicamente la modifica
della maschera dei segnali (di solito attivandone uno specifico) insieme alla
-sospensione del processo lo standard POSIX ha previsto la funzione
+sospensione del processo lo standard POSIX ha previsto la funzione di sistema
\funcd{sigsuspend}, il cui prototipo è:
-\begin{prototype}{signal.h}
-{int sigsuspend(const sigset\_t *mask)}
-
- Imposta la \textit{signal mask} specificata, mettendo in attesa il processo.
-
- \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
- errore, nel qual caso \var{errno} assumerà i valori:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int sigsuspend(const sigset\_t *mask)}
+\fdesc{Imposta la maschera dei segnali mettendo in attesa il processo.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
\item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
- \end{errlist}}
-\end{prototype}
+ \end{errlist}
+}
+\end{funcproto}
Come esempio dell'uso di queste funzioni proviamo a riscrivere un'altra volta
l'esempio di implementazione di \code{sleep}. Abbiamo accennato in
\itindex{deadlock} deadlock dovuto all'arrivo del segnale prima
dell'esecuzione di \func{sigsuspend}.
-\itindend{signal~mask}
+\index{maschera dei segnali|)}
\subsection{Criteri di programmazione per i gestori dei segnali}
\section{Funzionalità avanzate}
\label{sec:sig_advanced_signal}
-
Tratteremo in questa ultima sezione alcune funzionalità avanzate relativa ai
segnali ed in generale ai meccanismi di notifica, a partire dalla funzioni
introdotte per la gestione dei cosiddetti ``\textsl{segnali real-time}'', alla
vari meccanismi di notifica\footnote{un campo di tipo \type{sigval\_t} è
presente anche nella struttura \struct{sigevent} (definita in
fig.~\ref{fig:struct_sigevent}) che viene usata dai meccanismi di notifica
- come quelli per i timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}), l'I/O
- asincrono (vedi sez.~\ref{sec:file_asyncronous_io}) o le code di messaggi
- POSIX (vedi sez.~\ref{sec:ipc_posix_mq}).} per restituire dati al gestore
-del segnale; in alcune definizioni essa viene identificata anche con
-l'abbreviazione \type{sigval\_t}.
+ come quelli per \itindex{POSIX~Timer~API} i timer POSIX (vedi
+ sez.~\ref{sec:sig_timer_adv}), l'I/O asincrono (vedi
+ sez.~\ref{sec:file_asyncronous_io}) o le code di messaggi POSIX (vedi
+ sez.~\ref{sec:ipc_posix_mq}).} per restituire dati al gestore del segnale;
+in alcune definizioni essa viene identificata anche con l'abbreviazione
+\type{sigval\_t}.
A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
inviare segnali \textit{real-time}, poiché non è in grado di fornire alcun
\subsection{La gestione avanzata delle temporizzazioni}
\label{sec:sig_timer_adv}
+% TODO: indicizzare i termini \itindex{POSIX~Timer~API} e HRT
+
+
Sia le funzioni per la gestione dei tempi viste in
sez.~\ref{sec:sys_cpu_times} che quelle per la gestione dei timer di
sez.~\ref{sec:sig_alarm_abort} sono state a lungo limitate dalla risoluzione
Per usare queste funzionalità ed ottenere risoluzioni temporali più accurate,
occorre però un opportuno supporto da parte del kernel, ed i cosiddetti
-\itindex{high~resolution~timer} \textit{high resolution timer} che consentono
-di fare ciò sono stati introdotti nel kernel ufficiale solo a partire dalla
-versione 2.6.21.\footnote{deve essere stata abilitata l'opzione di
- compilazione \texttt{CONFIG\_HIGH\_RES\_TIMERS}, erano però disponibili
+\itindex{High~Resolution~Timer~(HRT)} \textit{high resolution timer} che
+consentono di fare ciò sono stati introdotti nel kernel ufficiale solo a
+partire dalla versione 2.6.21.\footnote{deve essere stata abilitata l'opzione
+ di compilazione \texttt{CONFIG\_HIGH\_RES\_TIMERS}, erano però disponibili
anche in precedenza come patch facenti parte dello sviluppo delle estensioni
\textit{real-time} del kernel, per cui alcune distribuzioni possono avere
questo supporto anche con versioni precedenti del kernel.} Le funzioni
possibilità di perdere un segnale sotto carico.} tanto che nello standard
POSIX.1-2008 questa viene marcata come obsoleta, e ne viene fortemente
consigliata la sostituzione con nuova interfaccia definita dallo standard
-POSIX.1-2001 che va sotto il nome di \textit{Posix Timer API}. Questa
+POSIX.1-2001 che va sotto il nome di \textit{POSIX Timer API}. Questa
interfaccia è stata introdotta a partire dal kernel 2.6, anche se il supporto
di varie funzionalità è stato aggiunto solo in un secondo tempo.
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
-% LocalWords: pwait msgrcv msgsnd semop semtimedop
+% LocalWords: pwait msgrcv msgsnd semop semtimedop runnable
projects / gapil.git / blobdiff