\label{cha:signals}
I segnali sono il primo e più semplice meccanismo di comunicazione nei
-confronti dei processi. Non portano con sé nessuna informazione che non sia il
-loro tipo; si tratta in sostanza di un'interruzione software portata ad un
-processo.
+confronti dei processi. Nella loro versione originale essi portano con sé
+nessuna informazione che non sia il loro tipo; si tratta in sostanza di
+un'interruzione software portata ad un processo.
In genere essi vengono usati dal kernel per riportare ai processi situazioni
eccezionali (come errori di accesso, eccezioni aritmetiche, etc.) ma possono
partendo da una introduzione relativa ai concetti base con cui essi vengono
realizzati, per poi affrontarne la classificazione a secondo di uso e modalità
di generazione fino ad esaminare in dettaglio funzioni e le metodologie di
-gestione.
+gestione avanzate e le estensioni fatte all'interfaccia classica nelle nuovi
+versioni dello standard POSIX.
\section{Introduzione}
kernel che causa la generazione un particolare tipo di segnale.
Quando un processo riceve un segnale, invece del normale corso del programma,
-viene eseguita una azione di default o una apposita routine di gestione (il
-cosiddetto \textit{signal handler} o \textsl{manipolatore}) che può essere
-stata specificata dall'utente (nel qual caso si dice che si
-\textsl{intercetta} il segnale).
+viene eseguita una azione predefinita o una apposita routine di gestione
+(quello che da qui in avanti chiameremo il \textsl{gestore} del segnale,
+dall'inglese\textit{signal handler}) che può essere stata specificata
+dall'utente (nel qual caso si dice che si \textsl{intercetta} il segnale).
\subsection{Le \textsl{semantiche} del funzionamento dei segnali}
Nella \textsl{semantica inaffidabile} (quella implementata dalle prime
versioni di Unix) la routine di gestione del segnale specificata dall'utente
non resta attiva una volta che è stata eseguita; è perciò compito dell'utente
-stesso ripetere l'installazione della stessa all'interno della routine di
-gestione, in tutti i casi in cui si vuole che il manipolatore esterno resti
-attivo.
+stesso ripetere l'installazione all'interno del \textsl{gestore} del segnale,
+in tutti quei casi in cui si vuole che esso resti attivo.
In questo caso è possibile una situazione in cui i segnali possono essere
perduti. Si consideri il segmento di codice riportato in
\secref{fig:sig_old_handler}, nel programma principale viene installato un
-manipolatore (\texttt{\small 5}), ed in quest'ultimo la prima operazione
+gestore (\texttt{\small 5}), ed in quest'ultimo la prima operazione
(\texttt{\small 11}) è quella di reinstallare se stesso. Se nell'esecuzione
-del manipolatore un secondo segnale arriva prima che esso abbia potuto
-eseguire la reinstallazione, verrà eseguito il comportamento di default
-assegnato al segnale stesso, il che può comportare, a seconda dei casi, che il
-segnale viene perso (se il default era quello di ignorarlo) o la terminazione
-immediata del processo; in entrambi i casi l'azione prevista non verrà
-eseguita.
+del gestore un secondo segnale arriva prima che esso abbia potuto eseguire la
+reinstallazione, verrà eseguito il comportamento predefinito assegnato al
+segnale stesso, il che può comportare, a seconda dei casi, che il segnale
+viene perso (se l'impostazione predefinita era quello di ignorarlo) o la
+terminazione immediata del processo; in entrambi i casi l'azione prevista non
+verrà eseguita.
\begin{figure}[!htb]
\footnotesize \centering
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{Esempio di codice di un manipolatore di segnale per la semantica
+ \caption{Esempio di codice di un gestore di segnale per la semantica
inaffidabile.}
\label{fig:sig_old_handler}
\end{figure}
Questa è la ragione per cui l'implementazione dei segnali secondo questa
semantica viene chiamata \textsl{inaffidabile}; infatti la ricezione del
-segnale e la reinstallazione del suo manipolatore non sono operazioni
-atomiche, e sono sempre possibili delle race condition (sull'argomento vedi
-quanto detto in \secref{sec:proc_multi_prog}).
+segnale e la reinstallazione del suo gestore non sono operazioni
+atomiche, e sono sempre possibili delle race condition\index{race condition}
+(sull'argomento vedi quanto detto in \secref{sec:proc_multi_prog}).
Un'altro problema è che in questa semantica non esiste un modo per bloccare i
segnali quando non si vuole che arrivino; i processi possono ignorare il
di un segnale, pur mantenendo memoria del fatto che è avvenuto.
Nella semantica \textsl{affidabile} (quella utilizzata da Linux e da ogni Unix
-moderno) il manipolatore una volta installato resta attivo e non si hanno
+moderno) il gestore una volta installato resta attivo e non si hanno
tutti i problemi precedenti. In questa semantica i segnali vengono
\textsl{generati} dal kernel per un processo all'occorrenza dell'evento che
-causa il segnale. In genere questo viene fatto dal kernel settando l'apposito
+causa il segnale. In genere questo viene fatto dal kernel impostando l'apposito
campo della \var{task\_struct} del processo nella process table (si veda
\figref{fig:proc_task_struct}).
\textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
per tutto il tempo che passa fra la generazione del segnale e la sua consegna
esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
-procedura viene effettuata dallo scheduler quando, riprendendo l'esecuzione
-del processo in questione, verifica la presenza del segnale nella
-\var{task\_struct} e mette in esecuzione il manipolatore.
+procedura viene effettuata dallo scheduler\index{scheduler} quando,
+riprendendo l'esecuzione del processo in questione, verifica la presenza del
+segnale nella \var{task\_struct} e mette in esecuzione il gestore.
In questa semantica un processo ha la possibilità di bloccare la consegna dei
segnali, in questo caso, se l'azione per il suddetto segnale non è quella di
ignorarlo, il segnale resta \textsl{pendente} fintanto che il processo non lo
-sblocca (nel qual caso viene consegnato) o setta l'azione di default per
+sblocca (nel qual caso viene consegnato) o imposta l'azione corrispondente per
ignorarlo.
Si tenga presente che il kernel stabilisce cosa fare con un segnale che è
\subsection{La notifica dei segnali}
\label{sec:sig_notification}
-Come accennato quando un segnale viene generato, se la sua azione di default
+Come accennato quando un segnale viene generato, se la sua azione predefinita
non è quella di essere ignorato, il kernel prende nota del fatto nella
\var{task\_struct} del processo; si dice così che il segnale diventa
\textsl{pendente} (o \textit{pending}), e rimane tale fino al momento in cui
-verrà notificato al processo (o verrà specificata come azione di default
-quella di ignorarlo).
+verrà notificato al processo (o verrà specificata come azione quella di
+ignorarlo).
Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
-avviene non appena questo viene rimesso in esecuzione dallo scheduler che
-esegue l'azione specificata. Questo a meno che il segnale in questione non sia
-stato bloccato prima della notifica, nel qual caso l'invio non avviene ed il
-segnale resta \textsl{pendente} indefinitamente. Quando lo si sblocca il
-segnale \textsl{pendente} sarà subito notificato.
+avviene non appena questo viene rimesso in esecuzione dallo
+scheduler\index{scheduler} che esegue l'azione specificata. Questo a meno che
+il segnale in questione non sia stato bloccato prima della notifica, nel qual
+caso l'invio non avviene ed il segnale resta \textsl{pendente}
+indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
+notificato.
Si ricordi però che se l'azione specificata per un segnale è quella di essere
ignorato questo sarà scartato immediatamente al momento della sua generazione,
\begin{itemize*}
\item ignorare il segnale.
-\item catturare il segnale, ed utilizzare il manipolatore specificato.
-\item accettare l'azione di default per quel segnale.
+\item catturare il segnale, ed utilizzare il gestore specificato.
+\item accettare l'azione predefinita per quel segnale.
\end{itemize*}
Un programma può specificare queste scelte usando le due funzioni
\func{signal} e \func{sigaction} (vedi \secref{sec:sig_signal} e
-\secref{sec:sig_sigaction}). Se si è installato un manipolatore sarà
+\secref{sec:sig_sigaction}). Se si è installato un gestore sarà
quest'ultimo ad essere eseguito alla notifica del segnale. Inoltre il sistema
-farà si che mentre viene eseguito il manipolatore di un segnale, quest'ultimo
-venga automaticamente bloccato (così si possono evitare race condition).
+farà si che mentre viene eseguito il gestore di un segnale, quest'ultimo
+venga automaticamente bloccato (così si possono evitare race
+condition\index{race condition}).
Nel caso non sia stata specificata un'azione, viene utilizzata l'azione
standard che (come vedremo in \secref{sec:sig_standard}) è propria di ciascun
che i numeri dei segnali sono allocati progressivamente, essa corrisponde
anche al successivo del valore numerico assegnato all'ultimo segnale definito.
In \tabref{tab:sig_signal_list} si è riportato l'elenco completo dei segnali
-definiti in Linux (estratto dalle man page), comparati con quelli definiti in
-vari standard.
+definiti in Linux (estratto dalle pagine di manuale), comparati con quelli
+definiti in vari standard.
\begin{table}[htb]
\footnotesize
\textbf{Sigla} & \textbf{Significato} \\
\hline
\hline
- A & L'azione di default è terminare il processo. \\
- B & L'azione di default è ignorare il segnale. \\
- C & L'azione di default è terminare il processo e scrivere un \textit{core
+ A & L'azione predefinita è terminare il processo. \\
+ B & L'azione predefinita è ignorare il segnale. \\
+ C & L'azione predefinita è terminare il processo e scrivere un \textit{core
dump}. \\
- D & L'azione di default è fermare il processo. \\
+ D & L'azione predefinita è fermare il processo. \\
E & Il segnale non può essere intercettato. \\
F & Il segnale non può essere ignorato.\\
\hline
\end{tabular}
- \caption{Legenda delle azioni di default dei segnali riportate in
+ \caption{Legenda delle azioni predefinite dei segnali riportate in
\tabref{tab:sig_signal_list}.}
\label{tab:sig_action_leg}
\end{table}
-In \tabref{tab:sig_signal_list} si sono anche riportate le azioni di default
+In \tabref{tab:sig_signal_list} si sono anche riportate le azioni predefinite
di ciascun segnale (riassunte con delle lettere, la cui legenda completa è in
-\tabref{tab:sig_action_leg}), quando nessun manipolatore è installato un
+\tabref{tab:sig_action_leg}), quando nessun gestore è installato un
segnale può essere ignorato o causare la terminazione del processo. Nella
colonna standard sono stati indicati anche gli standard in cui ciascun segnale
è definito, secondo lo schema di \tabref{tab:sig_standard_leg}.
controllo \\
\macro{SIGINT} &PL & A & Interrupt da tastiera (\cmd{C-c}) \\
\macro{SIGQUIT} &PL & C & Quit da tastiera (\cmd{C-y}) \\
- \macro{SIGILL} &PL & C & Istruzione illegale \\
+ \macro{SIGILL} &PL & C & Istruzione illecita \\
\macro{SIGABRT} &PL & C & Segnale di abort da \func{abort} \\
\macro{SIGFPE} &PL & C & Errore aritmetico \\
\macro{SIGKILL} &PL &AEF& Segnale di terminazione forzata \\
\label{sec:sig_prog_error}
Questi segnali sono generati quando il sistema, o in certi casi direttamente
-l'hardware (come per i page fault non validi) rileva un qualche errore
-insanabile nel programma in esecuzione. In generale la generazione di questi
-segnali significa che il programma ha dei gravi problemi (ad esempio ha
+l'hardware (come per i \textit{page fault} non validi) rileva un qualche
+errore insanabile nel programma in esecuzione. In generale la generazione di
+questi segnali significa che il programma ha dei gravi problemi (ad esempio ha
dereferenziato un puntatore non valido o ha eseguito una operazione aritmetica
proibita) e l'esecuzione non può essere proseguita.
In genere si intercettano questi segnali per permettere al programma di
-terminare in maniera pulita, ad esempio per ripristinare i settaggi della
+terminare in maniera pulita, ad esempio per ripristinare le impostazioni della
console o eliminare i file di lock prima dell'uscita. In questo caso il
-manipolatore deve concludersi ripristinando l'azione di default e rialzando il
+gestore deve concludersi ripristinando l'azione predefinita e rialzando il
segnale, in questo modo il programma si concluderà senza effetti spiacevoli,
-ma riportando lo stesso stato di uscita che avrebbe avuto se il manipolatore
-non ci fosse stato.
+ma riportando lo stesso stato di uscita che avrebbe avuto se il gestore non ci
+fosse stato.
-L'azione di default per tutti questi segnali è causare la terminazione del
+L'azione predefinita per tutti questi segnali è causare la terminazione del
processo che li ha causati. In genere oltre a questo il segnale provoca pure
la registrazione su disco di un file di \textit{core dump} che viene scritto
in un file \file{core} nella directory corrente del processo al momento
derivi da \textit{floating point exception} si applica a tutti gli errori
aritmetici compresa la divisione per zero e l'overflow.
- Se il manipolatore ritorna il comportamento del processo è indefinito, ed
+ Se il gestore ritorna il comportamento del processo è indefinito, ed
ignorare questo segnale può condurre ad un ciclo infinito.
% Per questo segnale le cose sono complicate dal fatto che possono esserci
\item[\macro{SIGILL}] Il nome deriva da \textit{illegal instruction},
significa che il programma sta cercando di eseguire una istruzione
- privilegiata o inesistente, in generale del codice illegale. Poiché il
+ privilegiata o inesistente, in generale del codice illecito. Poiché il
compilatore del C genera del codice valido si ottiene questo segnale se il
file eseguibile è corrotto o si stanno cercando di eseguire dei dati.
Quest'ultimo caso può accadere quando si passa un puntatore sbagliato al
posto di un puntatore a funzione, o si eccede la scrittura di un vettore di
una variabile locale, andando a corrompere lo stack. Lo stesso segnale viene
generato in caso di overflow dello stack o di problemi nell'esecuzione di un
- manipolatore. Se il manipolatore ritorna il comportamento del processo è
+ gestore. Se il gestore ritorna il comportamento del processo è
indefinito.
\item[\macro{SIGSEGV}] Il nome deriva da \textit{segment violation}, e
significa che il programma sta cercando di leggere o scrivere in una zona di
memoria protetta al di fuori di quella che gli è stata riservata dal
sistema. In genere è il meccanismo della protezione della memoria che si
- accorge dell'errore ed il kernel genera il segnale. Se il manipolatore
+ accorge dell'errore ed il kernel genera il segnale. Se il gestore
ritorna il comportamento del processo è indefinito.
È tipico ottenere questo segnale dereferenziando un puntatore nullo o non
programma può dover eseguire una serie di azioni di pulizia prima di
terminare, come salvare informazioni sullo stato in cui si trova, cancellare
file temporanei, o ripristinare delle condizioni alterate durante il
-funzionamento (come il modo del terminale o i settaggi di una qualche
+funzionamento (come il modo del terminale o le impostazioni di una qualche
periferica).
-L'azione di default di questi segnali è di terminare il processo, questi
+L'azione predefinita di questi segnali è di terminare il processo, questi
segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\macro{SIGTERM}] Il nome sta per \textit{terminate}. È un segnale
INTR (interrupt, generato dalla sequenza \macro{C-c}).
\item[\macro{SIGQUIT}] È analogo a \macro{SIGINT} con la differenze che è
controllato da un'altro carattere di controllo, QUIT, corrispondente alla
- sequenza \verb|C-\|. A differenza del precedente l'azione di default,
- oltre alla terminazione del processo, comporta anche la creazione di un core
- dump.
+ sequenza \verb|C-\|. A differenza del precedente l'azione predefinita, oltre
+ alla terminazione del processo, comporta anche la creazione di un core dump.
In genere lo si può pensare come corrispondente ad una condizione di
errore del programma rilevata dall'utente. Per questo motivo non è opportuno
- fare eseguire al manipolatore di questo segnale le operazioni di pulizia
+ fare eseguire al gestore di questo segnale le operazioni di pulizia
normalmente previste (tipo la cancellazione di file temporanei), dato che in
certi casi esse possono eliminare informazioni utili nell'esame dei core
dump.
processo da parte di \macro{SIGKILL} costituirebbe un malfunzionamento del
kernel). Talvolta è il sistema stesso che può generare questo segnale quando
per condizioni particolari il processo non può più essere eseguito neanche
- per eseguire un manipolatore.
+ per eseguire un gestore.
\item[\macro{SIGHUP}] Il nome sta per \textit{hang-up}. Segnala che il
terminale dell'utente si è disconnesso (ad esempio perché si è interrotta la
rete). Viene usato anche per riportare la terminazione del processo di
\label{sec:sig_alarm}
Questi segnali sono generati dalla scadenza di un timer. Il loro comportamento
-di default è quello di causare la terminazione del programma, ma con questi
-segnali la scelta di default è irrilevante, in quanto il loro uso presuppone
-sempre la necessità di un manipolatore. Questi segnali sono:
+predefinito è quello di causare la terminazione del programma, ma con questi
+segnali la scelta predefinita è irrilevante, in quanto il loro uso presuppone
+sempre la necessità di un gestore. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\macro{SIGALRM}] Il nome sta per \textit{alarm}. Segnale la scadenza di
un timer misurato sul tempo reale o sull'orologio di sistema. È normalmente
questo occorre comunque usare \func{fcntl} per abilitare un file descriptor a
generare questi segnali.
-L'azione di default è di essere ignorati. Questi segnali sono:
+L'azione predefinita è di essere ignorati. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\macro{SIGIO}] Questo segnale viene inviato quando un file descriptor è
pronto per eseguire dell'input/output. In molti sistemi solo i socket e i
cui si trattano gli argomenti relativi. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\macro{SIGCHLD}] Questo è il segnale mandato al processo padre quando un
- figlio termina o viene fermato. L'azione di default è di ignorare il
+ figlio termina o viene fermato. L'azione predefinita è di ignorare il
segnale, la sua gestione è trattata in \secref{sec:proc_wait}.
\item[\macro{SIGCLD}] Per Linux questo è solo un segnale identico al
precedente, il nome è obsoleto e andrebbe evitato.
\item[\macro{SIGCONT}] Il nome sta per \textit{continue}. Il segnale viene
usato per fare ripartire un programma precedentemente fermato da
\macro{SIGSTOP}. Questo segnale ha un comportamento speciale, e fa sempre
- ripartire il processo prima della sua consegna. Il comportamento di default
+ ripartire il processo prima della sua consegna. Il comportamento predefinito
è di fare solo questo; il segnale non può essere bloccato. Si può anche
- installare un manipolatore, ma il segnale provoca comunque il riavvio del
+ installare un gestore, ma il segnale provoca comunque il riavvio del
processo.
La maggior pare dei programmi non hanno necessità di intercettare il
segnale, in quanto esso è completamente trasparente rispetto all'esecuzione
che riparte senza che il programma noti niente. Si possono installare dei
- manipolatori per far si che un programma produca una qualche azione speciale
+ gestori per far si che un programma produca una qualche azione speciale
se viene fermato e riavviato, come per esempio riscrivere un prompt, o
inviare un avviso.
-\item[\macro{SIGSTOP}] Il segnale ferma un processo (lo porta in uno stato di
- sleep); il segnale non può essere né intercettato, né ignorato, né bloccato.
+\item[\macro{SIGSTOP}] Il segnale ferma un processo (lo porta cioè in uno
+ stato di sleep, vedi \secref{sec:proc_sched}); il segnale non può essere né
+ intercettato, né ignorato, né bloccato.
\item[\macro{SIGTSTP}] Il nome sta per \textit{interactive stop}. Il segnale
ferma il processo interattivamente, ed è generato dal carattere SUSP
- (prodotto dalla combinazione \macro{C-z}), ed al contrario di
+ (prodotto dalla combinazione \cmd{C-z}), ed al contrario di
\macro{SIGSTOP} può essere intercettato e ignorato. In genere un programma
- installa un manipolatore per questo segnale quando vuole lasciare il sistema
+ installa un gestore per questo segnale quando vuole lasciare il sistema
o il terminale in uno stato definito prima di fermarsi; se per esempio un
- programma ha disabilitato l'eco sul terminale può installare un manipolatore
+ programma ha disabilitato l'eco sul terminale può installare un gestore
per riabilitarlo prima di fermarsi.
\item[\macro{SIGTTIN}] Un processo non può leggere dal terminale se esegue una
- sessione di lavoro in background. Quando un processo in background tenta di
- leggere da un terminale viene inviato questo segnale a tutti i processi
- della sessione di lavoro. L'azione di default è di fermare il processo.
- L'argomento è trattato in \secref{sec:sess_xxx}.
+ sessione di lavoro in \textit{background}. Quando un processo in background
+ tenta di leggere da un terminale viene inviato questo segnale a tutti i
+ processi della sessione di lavoro. L'azione predefinita è di fermare il
+ processo. L'argomento è trattato in \secref{sec:sess_job_control_overview}.
\item[\macro{SIGTTOU}] Segnale analogo al precedente \macro{SIGTTIN}, ma
generato quando si tenta di scrivere o modificare uno dei modi del
- terminale. L'azione di default è di fermare il processo, l'argomento è
- trattato in \secref{sec:sess_xxx}.
+ terminale. L'azione predefinita è di fermare il processo, l'argomento è
+ trattato in \secref{sec:sess_job_control_overview}.
\end{basedescript}
che impediscono il completamento dell'esecuzione dovute all'interazione con il
resto del sistema.
-L'azione di default di questi segnali è di terminare il processo, questi
+L'azione predefinita di questi segnali è di terminare il processo, questi
segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\macro{SIGPIPE}] Sta per \textit{Broken pipe}. Se si usano delle pipe o
\item[\macro{SIGUSR2}] Insieme a \macro{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 manipolatore. L'azione di
- default è terminare il processo.
+ eseguire a richiesta una operazione utilizzando un gestore. L'azione
+ predefinita è di terminare il processo.
\item[\macro{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
programmi testuali per riformattare l'uscita su schermo quando si cambia
- dimensione a quest'ultimo. L'azione di default è di essere ignorato.
+ dimensione a quest'ultimo. L'azione predefinita è di essere ignorato.
\item[\macro{SIGINFO}] Il segnale indica una richiesta di informazioni. È
usato con il controllo di sessione, causa la stampa di informazioni da parte
del processo leader del gruppo associato al terminale di controllo, gli
\func{strsignal} e \func{psignal}, che stampano un messaggio di descrizione
dato il numero. In genere si usano quando si vuole notificare all'utente il
segnale avvenuto (nel caso di terminazione di un processo figlio o di un
-manipolatore che gestisce più segnali); la prima funzione è una estensione
+gestore che gestisce più segnali); la prima funzione è una estensione
GNU, accessibile avendo definito \macro{\_GNU\_SOURCE}, ed è analoga alla
funzione \func{strerror} (si veda \secref{sec:sys_strerror}) per gli errori:
\begin{prototype}{string.h}{char *strsignal(int signum)}
eventi che possono accadere in un qualunque momento durante l'esecuzione di un
programma. Per questa loro caratteristica la loro gestione non può essere
effettuata all'interno del normale flusso di esecuzione dello stesso, ma è
-delegata appunto agli eventuali manipolatori che si sono installati.
+delegata appunto agli eventuali gestori che si sono installati.
In questa sezione vedremo come si effettua gestione dei segnali, a partire
dalla loro interazione con le system call, passando per le varie funzioni che
-permettono di installare i manipolatori e controllare le reazioni di un
+permettono di installare i gestori e controllare le reazioni di un
processo alla loro occorrenza.
loro stretta relazione con la creazione di nuovi processi.
Come accennato in \secref{sec:proc_fork} quando viene creato un nuovo processo
-esso eredita dal padre sia le azioni che sono state settate per i singoli
+esso eredita dal padre sia le azioni che sono state impostate per i singoli
segnali, che la maschera dei segnali bloccati (vedi \secref{sec:sig_sigmask}).
Invece tutti i segnali pendenti e gli allarmi vengono cancellati; essi infatti
devono essere recapitati solo al padre, al figlio dovranno arrivare solo i
Quando si mette in esecuzione un nuovo programma con \func{exec} (si ricordi
quanto detto in \secref{sec:proc_exec}) tutti i segnali per i quali è stato
-installato un manipolatore vengono resettati a \macro{SIG\_DFL}. Non ha più
+installato un gestore vengono reimpostati a \macro{SIG\_DFL}. Non ha più
senso infatti fare riferimento a funzioni definite nel programma originario,
che non sono presenti nello spazio di indirizzi del nuovo programma.
Si noti che questo vale solo per le azioni per le quali è stato installato un
-manipolatore; viene mantenuto invece ogni eventuale settaggio dell'azione a
-\macro{SIG\_IGN}. Questo permette ad esempio alla shell di settare ad
+gestore; viene mantenuto invece ogni eventuale impostazione dell'azione a
+\macro{SIG\_IGN}. Questo permette ad esempio alla shell di impostare ad
\macro{SIG\_IGN} le risposte per \macro{SIGINT} e \macro{SIGQUIT} per i
programmi eseguiti in background, che altrimenti sarebbero interrotti da una
successiva pressione di \texttt{C-c} o \texttt{C-y}.
segnale. Esse sono dette \textsl{veloci} in quanto la loro esecuzione è
sostanzialmente immediata; la risposta al segnale viene sempre data dopo che
la system call è stata completata, in quanto attendere per eseguire un
-manipolatore non comporta nessun inconveniente.
+gestore non comporta nessun inconveniente.
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
-impossibile una risposta pronta al segnale, per cui il manipolatore viene
+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:
\begin{itemize}
\item la funzione \func{wait} (se nessun processo figlio è ancora terminato).
\end{itemize}
-In questo caso si pone il problema di cosa fare una volta che il manipolatore
+In questo caso si pone il problema di cosa fare una volta che il gestore
sia ritornato. La scelta originaria dei primi Unix era quella di far ritornare
anche la system call restituendo l'errore di \macro{EINTR}. Questa è a
tutt'oggi una scelta corrente, ma comporta che i programmi che usano dei
-manipolatori controllino lo stato di uscita delle funzioni per ripeterne la
+gestori controllino lo stato di uscita delle funzioni per ripeterne la
chiamata qualora l'errore fosse questo.
Dimenticarsi di richiamare una system call interrotta da un segnale è un
\begin{prototype}{signal.h}
{sighandler\_t signal(int signum, sighandler\_t handler)}
- Installa la funzione di gestione \param{handler} (il manipolatore) per il
+ Installa la funzione di gestione \param{handler} (il gestore) per il
segnale \param{signum}.
- \bodydesc{La funzione ritorna il precedente manipolatore in caso di successo
+ \bodydesc{La funzione ritorna il precedente gestore in caso di successo
o \macro{SIG\_ERR} in caso di errore.}
\end{prototype}
operatori del C, senza di esse si sarebbe definita una funzione che ritorna
un puntatore a \ctyp{void} e non un puntatore ad una funzione \ctyp{void}.}
La funzione \func{signal} quindi restituisce e prende come secondo argomento
-un puntatore a una funzione di questo tipo, che è appunto il manipolatore del
+un puntatore a una funzione di questo tipo, che è appunto il gestore del
segnale.
Il numero di segnale passato in \param{signum} può essere indicato
direttamente con una delle costanti definite in \secref{sec:sig_standard}. Il
-manipolatore \param{handler} invece, oltre all'indirizzo della funzione da
-chiamare all'occorrenza del segnale, può assumere anche i due valori costanti
+gestore \param{handler} invece, oltre all'indirizzo della funzione da chiamare
+all'occorrenza del segnale, può assumere anche i due valori costanti
\macro{SIG\_IGN} con cui si dice ignorare il segnale e \macro{SIG\_DFL} per
-installare l'azione di di default.\footnote{si ricordi però che i due segnali
+reinstallare l'azione predefinita.\footnote{si ricordi però che i due segnali
\macro{SIGKILL} e \macro{SIGSTOP} non possono essere ignorati né
intercettati.}
La funzione restituisce l'indirizzo dell'azione precedente, che può essere
salvato per poterlo ripristinare (con un'altra chiamata a \func{signal}) in un
-secondo tempo. Si ricordi che se si setta come azione \macro{SIG\_IGN} (o si
-setta un \macro{SIG\_DFL} per un segnale il cui default è di essere ignorato),
-tutti i segnali pendenti saranno scartati, e non verranno mai notificati.
+secondo tempo. Si ricordi che se si imposta come azione \macro{SIG\_IGN} (o si
+imposta un \macro{SIG\_DFL} per un segnale la cui azione predefinita è di
+essere ignorato), tutti i segnali pendenti saranno scartati, e non verranno
+mai notificati.
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 manipolatore viene disinstallato alla sua chiamata,
+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 resettando il
-manipolatore 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}.
+\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}.
È da tenere presente che, seguendo lo standard POSIX, il comportamento di un
processo che ignora i segnali \macro{SIGFPE}, \macro{SIGILL}, o
\macro{SIGSEGV} (qualora non originino da una \func{kill} o una \func{raise})
-è indefinito. Un manipolatore che ritorna da questi segnali può dare luogo ad
+è indefinito. Un gestore che ritorna da questi segnali può dare luogo ad
un ciclo infinito.
Il valore di \param{sig} specifica il segnale che si vuole inviare e può
essere specificato con una delle macro definite in
\secref{sec:sig_classification}. In genere questa funzione viene usata per
-riprodurre il comportamento di default di un segnale che sia stato
+riprodurre il comportamento predefinito di un segnale che sia stato
intercettato. In questo caso, una volta eseguite le operazioni volute, il
-manipolatore potrà reinstallare l'azione di default, e attivarla con
-\func{raise}.
+gestore potrà reinstallare l'azione predefinita, e attivarla con \func{raise}.
Se invece si vuole inviare un segnale ad un altro processo occorre utilizzare
la funzione \func{kill}; il cui prototipo è:
\funcdecl{int kill(pid\_t pid, int sig)} Invia il segnale \param{sig} al
processo specificato con \param{pid}.
- \bodydesc{ La funzione restituisce 0 in caso di successo e -1 in caso di
- errore nel qual caso \var{errno} può assumere i valori:
+ \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[\macro{EINVAL}] Il segnale specificato non esiste.
\item[\macro{ESRCH}] Il processo selezionato non esiste.
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_xxx}).
+\secref{sec:sess_proc_group}).
Solo l'amministratore può inviare un segnale ad un processo qualunque, in
-tutti gli altri casi il \textit{real user id} o l'\textit{effective user id}
-del processo chiamante devono corrispondere al \textit{real user id} o al
-\textit{saved user id} della destinazione. Fa eccezione il caso in cui il
-segnale inviato sia \macro{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 \secref{sec:sig_termination}),
-non è possibile inviare al processo 1 (cioè a \cmd{init}) segnali per i quali
-esso non abbia un manipolatore installato.
+tutti gli altri casi l'userid reale o l'userid effettivo del processo
+chiamante devono corrispondere all'userid reale o all'userid salvato della
+destinazione. Fa eccezione il caso in cui il segnale inviato sia
+\macro{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 \secref{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
\param{value} sul timer specificato da \func{which}.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} può assumere i valori \macro{EINVAL} e
+ errore, nel qual caso \var{errno} assumerà uno dei valori \macro{EINVAL} o
\macro{EFAULT}.}
\end{prototype}
\label{tab:sig_setitimer_values}
\end{table}
-Il valore della struttura specificata \param{value} viene usato per settare il
+Il valore della struttura specificata \param{value} viene usato per impostare il
timer, se il puntatore \param{ovalue} non è nullo il precedente valore viene
salvato qui. I valori dei timer devono essere indicati attraverso una
-struttura \var{itimerval}, definita in \figref{fig:file_stat_struct}.
+struttura \type{itimerval}, definita in \figref{fig:file_stat_struct}.
La struttura è composta da due membri, il primo, \var{it\_interval} definisce
il periodo del timer; il secondo, \var{it\_value} il tempo mancante alla
permette una precisione fino al microsecondo.
Ciascun timer decrementa il valore di \var{it\_value} fino a zero, poi invia
-il segnale e resetta \var{it\_value} al valore di \var{it\_interval}, in
+il segnale e reimposta \var{it\_value} al valore di \var{it\_interval}, in
questo modo il ciclo verrà ripetuto; se invece il valore di \var{it\_interval}
è nullo il timer si ferma.
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \var{itimerval}, che definisce i valori dei timer di
+ \caption{La struttura \type{itimerval}, che definisce i valori dei timer di
sistema.}
\label{fig:sig_itimerval}
\end{figure}
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 manipolatore ritorna, la
+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 manipolatore sia la stessa
+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
quello di usare la funzione \func{pause}, il cui prototipo è:
\begin{prototype}{unistd.h}{int pause(void)}
- Pone il processo in stato di sleep fino al ritorno di un manipolatore.
+ 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 manipolatore è ritornato, nel qual caso restituisce -1 e setta
- \var{errno} a \macro{EINTR}.}
+ il relativo gestore è ritornato, nel qual caso restituisce -1 e
+ \var{errno} assumerà il valore \macro{EINTR}.}
\end{prototype}
La funzione segnala sempre una condizione di errore (il successo sarebbe
questo sia sotto BSD4.3 che in SUSv2 è stata definita la funzione
\func{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 man page almeno dalla versione 2.2.2.} seguono
-quella di SUSv2 che prevede il seguente prototipo:
+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} è settata a \macro{EINTR}.}
+ caso di errore, nel qual caso \var{errno} assumerà il valore
+ \macro{EINTR}.}
\end{prototype}
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} è settata a
+ caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\macro{EINVAL}] si è specificato un numero di secondi negativo o un
numero di nanosecondi maggiore di 999.999.999.
nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
specificato, ma prima che il processo possa tornare ad essere eseguito
-occorrerà almeno attendere il successivo giro di scheduler e cioè un tempo che
-a seconda dei casi può arrivare fino a 1/\macro{HZ}, (sempre che il sistema
-sia scarico ed il processa venga immediatamente rimesso in esecuzione); per
-questo motivo il valore restituito in \param{rem} è sempre arrotondato al
-multiplo successivo di 1/\macro{HZ}.
+occorrerà almeno attendere il successivo giro di scheduler\index{scheduler} e
+cioè un tempo che a seconda dei casi può arrivare fino a 1/\macro{HZ}, (sempre
+che il sistema sia scarico ed il processa venga immediatamente rimesso in
+esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
+arrotondato al multiplo successivo di 1/\macro{HZ}.
In realtà è possibile ottenere anche pause più precise del centesimo di
secondo usando politiche di scheduling real time come \macro{SCHED\_FIFO} o
\subsection{Un esempio elementare}
\label{sec:sig_sigchld}
-Un semplice esempio per illustrare il funzionamento di un manipolatore di
-segnale è quello della gestione di \macro{SIGCHLD}. Abbiamo visto in
+Un semplice esempio per illustrare il funzionamento di un gestore di segnale è
+quello della gestione di \macro{SIGCHLD}. Abbiamo visto in
\secref{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 \macro{SIGCLD} e viene trattato in maniera speciale; in
- System V infatti se si setta esplicitamente l'azione a \macro{SIG\_IGN} il
+ System V infatti se si imposta esplicitamente l'azione a \macro{SIG\_IGN} il
segnale non viene generato ed il sistema non genera zombie (lo stato di
terminazione viene scartato senza dover chiamare una \func{wait}). L'azione
- di default è sempre quella di ignorare il segnale, ma non attiva questo
+ 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 \macro{SIGCLD} come sinonimo di \macro{SIGCHLD}.} In generale
dunque, quando non interessa elaborare lo stato di uscita di un processo, si
-può completare la gestione della terminazione installando un manipolatore per
+può completare la gestione della terminazione installando un gestore per
\macro{SIGCHLD} il cui unico compito sia quello chiamare \func{waitpid} per
completare la procedura di terminazione in modo da evitare la formazione di
zombie.
-In \figref{fig:sig_sigchld_handl} è mostrato il codice della nostra
-implementazione del manipolatore; se aggiungiamo al codice di
-\file{ForkTest.c} l'installazione di questo manipolatore potremo verificare che
-ripetendo l'esempio visto in \secref{sec:proc_termination} che non si ha più
-la creazione di zombie.
+In \figref{fig:sig_sigchld_handl} è mostrato il codice contenente una
+implementazione generica di una routine di gestione per \macro{SIGCHLD}, (che
+si trova nei sorgenti allegati nel file \file{HandSIGCHLD.c}); se ripetiamo i
+test di \secref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione
+\cmd{-s} (che si limita ad effettuare l'installazione di questa funzione come
+gestore di \macro{SIGCHLD}) potremo verificare che non si ha più la creazione
+di zombie.
% è pertanto
% naturale usare un esempio che ci permette di concludere la trattazione della
% terminazione dei processi.
% In questo caso si è tratterà di illustrare un esempio relativo ad un
-% manipolatore per che è previsto ritornare,
+% gestore per che è previsto ritornare,
\begin{figure}[!htb]
#include <sys/wait.h>
#include "macro.h"
-void sigchld_hand(int sig)
+void HandSIGCHLD(int sig)
{
int errno_save;
int status;
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{Un manipolatore per il segnale \texttt{SIGCHLD}.}
+ \caption{Codice di una funzione generica di gestione per il segnale
+ \texttt{SIGCHLD}.}
\label{fig:sig_sigchld_handl}
\end{figure}
-Il codice del manipolatore è di lettura immediata; come buona norma di
+Il codice del gestore è di lettura immediata; come buona norma di
programmazione (si ricordi quanto accennato \secref{sec:sys_errno}) si
comincia (\texttt{\small 12-13}) con il salvare lo stato corrente di
-\var{errno}, in modo da poterlo ripristinare prima del ritorno del
-manipolatore (\texttt{\small 22-23}). In questo modo si preserva il valore
-della variabile visto dal corso di esecuzione principale del processo, che
-sarebbe altrimenti sarebbe sovrascritto dal valore restituito nella successiva
-chiamata di \func{wait}.
+\var{errno}, in modo da poterlo ripristinare prima del ritorno del gestore
+(\texttt{\small 22-23}). In questo modo si preserva il valore della variabile
+visto dal corso di esecuzione principale del processo, che sarebbe altrimenti
+sarebbe sovrascritto dal valore restituito nella successiva chiamata di
+\func{wait}.
-Il compito principale del manipolatore è quello di ricevere lo stato di
+Il compito principale del gestore è quello di ricevere lo stato di
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 manipolatore possa passare un
-certo lasso di tempo e niente ci assicura che il manipolatore venga eseguito
+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
processo ne viene recapitato soltanto uno.
Le funzioni esaminate finora fanno riferimento ad alle modalità più elementari
della gestione dei segnali; non si sono pertanto ancora prese in
-considerazione le tematiche più complesse, collegate alle varie race condition
-che i segnali possono generare e alla natura asincrona degli stessi.
+considerazione le tematiche più complesse, collegate alle varie race
+condition\index{race condition} che i segnali possono generare e alla natura
+asincrona degli stessi.
Affronteremo queste problematiche in questa sezione, partendo da un esempio
che le evidenzi, per poi prendere in esame le varie funzioni che permettono di
\figref{fig:sig_sleep_wrong}.
Dato che è nostra intenzione utilizzare \macro{SIGALRM} il primo passo della
-nostra implementazione di sarà quello di installare il relativo manipolatore
+nostra implementazione di sarà quello di installare il relativo gestore
salvando il precedente (\texttt{\small 14-17}). Si effettuerà poi una
chiamata ad \func{alarm} per specificare il tempo d'attesa per l'invio del
segnale a cui segue la chiamata a \func{pause} per fermare il programma
(\texttt{\small 17-19}) fino alla sua ricezione. Al ritorno di \func{pause},
-causato dal ritorno del manipolatore (\texttt{\small 1-9}), si ripristina il
-manipolatore originario (\texttt{\small 20-21}) restituendo l'eventuale tempo
+causato dal ritorno del gestore (\texttt{\small 1-9}), si ripristina il
+gestore originario (\texttt{\small 20-21}) restituendo l'eventuale tempo
rimanente (\texttt{\small 22-23}) che potrà essere diverso da zero qualora
l'interruzione di \func{pause} venisse causata da un altro segnale.
Questo codice però, a parte il non gestire il caso in cui si è avuta una
precedente chiamata a \func{alarm} (che si è tralasciato per brevità),
-presenta una pericolosa race condition. Infatti se il processo viene
-interrotto fra la chiamata di \func{alarm} e \func{pause} può capitare (ad
-esempio se il sistema è molto carico) che il tempo di attesa scada prima
-dell'esecuzione quest'ultima, cosicché essa sarebbe eseguita dopo l'arrivo di
-\macro{SIGALRM}. In questo caso ci si troverebbe di fronte ad un deadlock, in
-quanto \func{pause} non verrebbe mai più interrotta (se non in caso di un
-altro segnale).
+presenta una pericolosa race condition\index{race condition}. Infatti se il
+processo viene interrotto fra la chiamata di \func{alarm} e \func{pause} può
+capitare (ad esempio se il sistema è molto carico) che il tempo di attesa
+scada prima dell'esecuzione quest'ultima, cosicché essa sarebbe eseguita dopo
+l'arrivo di \macro{SIGALRM}. In questo caso ci si troverebbe di fronte ad un
+deadlock, in quanto \func{pause} non verrebbe mai più interrotta (se non in
+caso di un altro segnale).
Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
SVr2) usando la funzione \func{longjmp} (vedi \secref{sec:proc_longjmp}) per
-uscire dal manipolatore; 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 \figref{fig:sig_sleep_incomplete}.
\label{fig:sig_sleep_incomplete}
\end{figure}
-In questo caso il manipolatore (\texttt{\small 18-26}) non ritorna come in
+In questo caso il gestore (\texttt{\small 18-26}) non ritorna come in
\figref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 24}) per
rientrare nel corpo principale del programma; dato che in questo caso il
valore di uscita di \func{setjmp} è 1, grazie alla condizione in
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 manipolatore, in questo caso
-l'esecuzione non riprenderà nel manipolatore in questione, ma nel ciclo
+infatti il segnale di allarme interrompe un altro gestore, in questo caso
+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 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 è settare
-nel manipolatore un opportuno flag da controllare nel corpo principale del
+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
\figref{fig:sig_event_wrong}).
\label{fig:sig_event_wrong}
\end{figure}
-La logica è quella di far settare al manipolatore (\texttt{\small 14-19}) una
+La logica è quella di far impostare al gestore (\texttt{\small 14-19}) una
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}).
Questo è il tipico esempio di caso, già citato in \secref{sec:proc_race_cond},
-in cui si genera una race condition; se infatti il 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.
+in cui si genera una race condition\index{race condition}; se infatti il
+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.
Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono
funzioni più sofisticate di quelle illustrate finora, che hanno origine dalla
\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} settata a
- \macro{EINVAL} (il solo errore possibile è che \param{signum} non sia un
- segnale valido).}
+ altrimenti. In caso di errore tutte ritornano -1, con \var{errno}
+ impostata a \macro{EINVAL} (il solo errore possibile è che \param{signum}
+ non sia un segnale valido).}
\end{functions}
Dato che in generale non si può fare conto sulle caratteristiche di una
errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\macro{EINVAL}] Si è specificato un numero di segnale invalido o si è
- cercato di installare il manipolatore per \macro{SIGKILL} o
+ cercato di installare il gestore per \macro{SIGKILL} o
\macro{SIGSTOP}.
\item[\macro{EFAULT}] Si sono specificati indirizzi non validi.
\end{errlist}}
\end{prototype}
La funzione serve ad installare una nuova \textsl{azione} per il segnale
-\param{signum}; si parla di \textsl{azione} e non di \textsl{manipolatore}
+\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
\end{figure}
Il campo \var{sa\_mask} serve ad indicare l'insieme dei segnali che devono
-essere bloccati durante l'esecuzione del manipolatore, ad essi viene comunque
+essere bloccati durante l'esecuzione del gestore, ad essi viene comunque
sempre aggiunto il segnale che ne ha causato la chiamata, a meno che non si
sia specificato con \var{sa\_flag} un comportamento diverso. Quando il
-manipolatore ritorna comunque la maschera dei segnali bloccati (vedi
+gestore ritorna comunque la maschera dei segnali bloccati (vedi
\secref{sec:sig_sigmask}) viene ripristinata al valore precedente
l'invocazione.
L'uso di questo campo permette ad esempio di risolvere il problema residuo
dell'implementazione di \code{sleep} mostrata in
\secref{fig:sig_sleep_incomplete}. In quel caso infatti se il segnale di
-allarme avesse interrotto un altro manipolatore questo non sarebbe stato
+allarme avesse interrotto un altro gestore questo non sarebbe stato
eseguito correttamente; la cosa poteva essere prevenuta installando gli altri
-manipolatori usando \var{sa\_mask} per bloccare \macro{SIGALRM} durante la
+gestori usando \var{sa\_mask} per bloccare \macro{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
fermato da uno dei segnali \macro{SIGSTOP},
\macro{SIGTSTP}, \macro{SIGTTIN} o
\macro{SIGTTOU}.\\
- \macro{SA\_ONESHOT} & Ristabilisce l'azione per il segnale al valore di
- default una volta che il manipolatore è stato
+ \macro{SA\_ONESHOT} & Ristabilisce l'azione per il segnale al valore
+ predefinito una volta che il gestore è stato
lanciato, riproduce cioè il comportamento della
semantica inaffidabile.\\
\macro{SA\_RESETHAND}& Sinonimo di \macro{SA\_ONESHOT}. \\
segnale; riproduce cioè il comportamento standard
di BSD.\\
\macro{SA\_NOMASK} & Evita che il segnale corrente sia bloccato durante
- l'esecuzione del manipolatore.\\
+ l'esecuzione del gestore.\\
\macro{SA\_NODEFER} & Sinonimo di \macro{SA\_NOMASK}.\\
\macro{SA\_SIGINFO} & Deve essere specificato quando si vuole usare un
- manipolatore in forma estesa usando
+ gestore in forma estesa usando
\var{sa\_sigaction} al posto di \var{sa\_handler}.\\
\macro{SA\_ONSTACK} & Stabilisce l'uso di uno stack alternativo per
- l'esecuzione del manipolatore (vedi
+ l'esecuzione del gestore (vedi
\secref{sec:sig_specific_features}).\\
\hline
\end{tabular}
\end{table}
Come si può notare in \figref{fig:sig_sigaction} \func{sigaction}
-permette\footnote{La possibilità è prevista dallo standard POSIX.1b, ma in
- Linux è stata aggiunta a partire dai kernel della serie 2.2.x. In precedenza
- era possibile ottenere alcune informazioni addizionali usando
- \var{sa\_handler} con un secondo parametro addizionale di tipo \var{struct
- sigcontext}, che adesso è deprecato.} di utilizzare due forme diverse di
-manipolatore, da specificare, a seconda dell'uso o meno del flag
-\macro{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 manipolatore in grado di ricevere informazioni più
-dettagliate dal sistema, attraverso la struttura \var{siginfo\_t}, riportata
-in \figref{fig:sig_siginfo_t}.
+permette\footnote{La possibilità è prevista dallo standard POSIX.1b, ed è
+ stata aggiunta nei kernel della serie 2.1.x con l'introduzione dei segnali
+ 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{struct sigcontext}, che adesso è
+ deprecato.} di utilizzare due forme diverse di gestore, da
+specificare, a seconda dell'uso o meno del flag \macro{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 \type{siginfo\_t}, riportata in
+\figref{fig:sig_siginfo_t}.
\begin{figure}[!htb]
\footnotesize \centering
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \var{siginfo\_t}.}
+ \caption{La struttura \type{siginfo\_t}.}
\label{fig:sig_siginfo_t}
\end{figure}
-Installando un manipolatore di tipo \var{sa\_sigaction} diventa allora
-possibile accedere alle informazioni restituite attraverso il puntatore a
-questa struttura. Tutti i segnali settano i campi \var{si\_signo}, che riporta
-il segnale ricevuto, \var{si\_errno}, che riporta il codice di errore, e
-\var{si\_code}, che viene usato per indicare la ragione per cui è stato emesso
-il segnale (come i dettagli sul tipo di errore per \macro{SIGFPE} e
-\macro{SIGILL}) ed ha valori diversi\footnote{un elenco dettagliato è
- disponibile nella man page di \func{sigaction}.} a seconda del tipo di
-segnale ricevuto.
-
-Il resto della struttura può essere definito come \ctyp{union} ed i valori
+Installando un gestore di tipo \var{sa\_sigaction} diventa allora possibile
+accedere alle informazioni restituite attraverso il puntatore a questa
+struttura. Tutti i segnali impostano i campi \var{si\_signo}, che riporta il
+numero del segnale ricevuto, \var{si\_errno}, che riporta, quando diverso da
+zero, il codice dell'errore associato al segnale, e \var{si\_code}, che viene
+usato dal kernel per specificare maggiori dettagli riguardo l'evento che ha
+causato l'emissione del segnale.
+
+In generale \var{si\_code} contiene, per i segnali generici, per quelli
+real-time e per tutti quelli inviati tramite \func{kill}, informazioni circa
+l'origine del segnale (se generato dal kernel, da un timer, da \func{kill},
+ecc.). Alcuni segnali però usano \var{si\_code} per fornire una informazione
+specifica: ad esempio i vari segnali di errore (\macro{SIGFPE},
+\macro{SIGILL}, \macro{SIGBUS} e \macro{SIGSEGV}) lo usano per fornire
+maggiori dettagli riguardo l'errore (come il tipo di errore aritmetico, di
+istruzione illecita o di violazione di memoria) mentre alcuni segnali di
+controllo (\macro{SIGCHLD}, \macro{SIGTRAP} e \macro{SIGPOLL}) forniscono
+altre informazioni speecifiche. 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}.
+
+Il resto della struttura è definito come \ctyp{union} ed i valori
eventualmente presenti dipendono dal segnale, così \macro{SIGCHLD} ed i
-segnali POSIX.1b\footnote{NdA trovare quale sono e completare l'informazione.}
-inviati tramite \func{kill} avvalorano \var{si\_pid} e \var{si\_uid} coi
-valori corrispondenti al processo che ha emesso il segnale, \macro{SIGILL},
-\macro{SIGFPE}, \macro{SIGSEGV} e \macro{SIGBUS} avvalorano \var{si\_addr} con
-l'indirizzo cui è avvenuto l'errore, \macro{SIGIO} (vedi
-\secref{sec:file_asyncronous_io}) e \macro{SIGPOLL} avvalorano \var{si\_fd}
-con il numero del file descriptor.
+segnali real-time (vedi \secref{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, \macro{SIGILL}, \macro{SIGFPE},
+\macro{SIGSEGV} e \macro{SIGBUS} avvalorano \var{si\_addr} con l'indirizzo cui
+è avvenuto l'errore, \macro{SIGIO} (vedi \secref{sec:file_asyncronous_io})
+avvalora \var{si\_fd} con il numero del file descriptor e \var{si\_band} per i
+dati urgenti su un socket.
Benché sia possibile usare nello stesso programma sia \func{sigaction} che
\func{signal} occorre molta attenzione, in quanto le due funzioni possono
interagire in maniera anomala. Infatti l'azione specificata con
\var{sigaction} contiene un maggior numero di informazioni rispetto al
-semplice indirizzo del manipolatore restituito da \func{signal}. Per questo
-motivo se si usa quest'ultima per installare un manipolatore sostituendone uno
+semplice indirizzo del gestore restituito da \func{signal}. Per questo
+motivo se si usa quest'ultima per installare un gestore sostituendone uno
precedentemente installato con \func{sigaction}, non sarà possibile effettuare
un ripristino corretto dello stesso.
Per questo è sempre opportuno usare \func{sigaction}, che è in grado di
-ripristinare correttamente un manipolatore precedente, anche se questo è stato
+ripristinare correttamente un gestore precedente, anche se questo è stato
installato con \func{signal}. In generale poi non è il caso di usare il valore
di ritorno di \func{signal} come campo \var{sa\_handler}, o viceversa, dato
che in certi sistemi questi possono essere diversi. In definitiva dunque, a
\label{sec:sig_sigmask}
Come spiegato in \secref{sec:sig_semantics} tutti i moderni sistemi unix-like
-permettono si bloccare temporaneamente (o di eliminare completamente, settando
+permettono si bloccare temporaneamente (o di eliminare completamente, impostando
\macro{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
l'insieme dei segnali la cui consegna è bloccata. Abbiamo accennato in
\secref{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 manipolatore,
+che essa può essere modificata, durante l'esecuzione di un gestore,
attraverso l'uso dal campo \var{sa\_mask} di \var{sigaction}.
Uno dei problemi evidenziatisi con l'esempio di \secref{fig:sig_event_wrong} è
\macro{SIG\_UNBLOCK} & I segnali specificati in \param{set} sono rimossi
dalla maschera dei segnali, specificare la
cancellazione di un segnale non bloccato è legale.\\
- \macro{SIG\_SETMASK} & La maschera dei segnali è settata al valore
+ \macro{SIG\_SETMASK} & La maschera dei segnali è impostata al valore
specificato da \param{set}.\\
\hline
\end{tabular}
\secref{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 manipolatore, ad esempio
+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.
Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
-dei casi di race condition restano aperte alcune possibilità legate all'uso di
-\func{pause}; il caso è simile a quello del problema illustrato nell'esempio
-di \secref{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 \func{sigsuspend}, il cui
-prototipo è:
+dei casi di race condition\index{race condition} restano aperte alcune
+possibilità legate all'uso di \func{pause}; il caso è simile a quello del
+problema illustrato nell'esempio di \secref{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
+\func{sigsuspend}, il cui prototipo è:
\begin{prototype}{signal.h}
{int sigsuspend(const sigset\_t *mask)}
- Setta la \textit{signal mask} specificata, mettendo in attesa il processo.
+ 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:
Come esempio dell'uso di queste funzioni proviamo a riscrivere un'altra volta
l'esempio di implementazione di \code{sleep}. Abbiamo accennato in
\secref{sec:sig_sigaction} come con \func{sigaction} sia possibile bloccare
-\macro{SIGALRM} nell'installazione dei manipolatori degli altri segnali, per
+\macro{SIGALRM} nell'installazione dei gestori degli altri segnali, per
poter usare l'implementazione vista in \secref{fig:sig_sleep_incomplete} senza
interferenze. Questo però comporta una precauzione ulteriore al semplice uso
della funzione, vediamo allora come usando la nuova interfaccia è possibile
\footnotesize \centering
\begin{minipage}[c]{15cm}
\begin{lstlisting}{}
-#include <unistd.h> /* unix standard library */
-#include <signal.h> /* POSIX signal library */
void alarm_hand(int);
unsigned int sleep(unsigned int seconds)
{
-/*
- * Variables definition
- */
struct sigaction new_action, old_action;
sigset_t old_mask, stop_mask, sleep_mask;
/* set the signal handler */
/* return remaining time */
return alarm(0);
}
-/*
- * Signal Handler for SIGALRM
- */
void alarm_hand(int sig)
{
return; /* just return to interrupt sigsuspend */
Per evitare i problemi di interferenza con gli altri segnali in questo caso
non si è usato l'approccio di \figref{fig:sig_sleep_incomplete} evitando l'uso
-di \func{longjmp}. Come in precedenza il manipolatore (\texttt{\small 35-37})
+di \func{longjmp}. Come in precedenza il gestore (\texttt{\small 35-37})
non esegue nessuna operazione, limitandosi a ritornare per interrompere il
programma messo in attesa.
La prima parte della funzione (\texttt{\small 11-15}) provvede ad installare
-l'opportuno manipolatore per \macro{SIGALRM}, salvando quello originario, che
+l'opportuno gestore per \macro{SIGALRM}, salvando quello originario, che
sarà ripristinato alla conclusione della stessa (\texttt{\small 28}); il passo
successivo è quello di bloccare \macro{SIGALRM} (\texttt{\small 17-19}) per
evitare che esso possa essere ricevuto dal processo fra l'esecuzione di
\var{sleep\_mask} per riattivare \macro{SIGALRM} all'esecuzione di
\func{sigsuspend}.
-In questo modo non sono più possibili race condition dato che \macro{SIGALRM}
-viene disabilitato con \func{sigprocmask} fino alla chiamata di
-\func{sigsuspend}. Questo metodo è assolutamente generale e può essere
-applicato a qualunque altra situazione in cui si deve attendere per un
+In questo modo non sono più possibili race condition\index{race condition}
+dato che \macro{SIGALRM} viene disabilitato con \func{sigprocmask} fino alla
+chiamata di \func{sigsuspend}. Questo metodo è assolutamente generale e può
+essere applicato a qualunque altra situazione in cui si deve attendere per un
segnale, i passi sono sempre i seguenti:
-\begin{enumerate}
+\begin{enumerate*}
\item Leggere la maschera dei segnali corrente e bloccare il segnale voluto
con \func{sigprocmask}.
\item Mandare il processo in attesa con \func{sigsuspend} abilitando la
ricezione del segnale voluto.
\item Ripristinare la maschera dei segnali originaria.
-\end{enumerate}
+\end{enumerate*}
Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi
riabilitarla immediatamente dopo, in questo modo si evita il deadlock dovuto
all'arrivo del segnale prima dell'esecuzione di \func{sigsuspend}.
di usare uno stack alternativo per i segnali; è cioè possibile fare usare al
sistema un altro stack (invece di quello relativo al processo, vedi
\secref{sec:proc_mem_layout}) solo durante l'esecuzione di un
-manipolatore. L'uso di uno stack alternativo è del tutto trasparente ai
-manipolatori, occorre però seguire una certa procedura:
-\begin{enumerate}
+gestore. L'uso di uno stack alternativo è del tutto trasparente ai
+gestori, occorre però seguire una certa procedura:
+\begin{enumerate*}
\item Allocare un'area di memoria di dimensione sufficiente da usare come
stack alternativo.
\item Usare la funzione \func{sigaltstack} per rendere noto al sistema
l'esistenza e la locazione dello stack alternativo.
-\item Quando si installa un manipolatore occorre usare \func{sigaction}
+\item Quando si installa un gestore occorre usare \func{sigaction}
specificando il flag \macro{SA\_ONSTACK} (vedi \tabref{tab:sig_sa_flag}) per
dire al sistema di usare lo stack alternativo durante l'esecuzione del
- manipolatore.
-\end{enumerate}
+ gestore.
+\end{enumerate*}
In genere il primo passo viene effettuato allocando un'opportuna area di
memoria con \code{malloc}; in \file{signal.h} sono definite due costanti,
allocare una quantità di spazio opportuna, in modo da evitare overflow. La
prima delle due è la dimensione canonica per uno stack di segnali e di norma è
sufficiente per tutti gli usi normali. La seconda è lo spazio che occorre al
-sistema per essere in grado di lanciare il manipolatore e la dimensione di uno
+sistema per essere in grado di lanciare il gestore e la dimensione di uno
stack alternativo deve essere sempre maggiore di questo valore. Quando si
-conosce esattamente quanto è lo spazio necessario al manipolatore gli si può
+conosce esattamente quanto è lo spazio necessario al gestore gli si può
aggiungere questo valore per allocare uno stack di dimensione sufficiente.
Come accennato per poter essere usato lo stack per i segnali deve essere
\func{exec} cancella ogni stack alternativo.
Abbiamo visto in \secref{fig:sig_sleep_incomplete} come si possa usare
-\func{longjmp} per uscire da un manipolatore rientrando direttamente nel corpo
-del programma; sappiamo però che nell'esecuzione di un manipolatore il segnale
+\func{longjmp} per uscire da un gestore rientrando direttamente nel corpo
+del programma; sappiamo però che nell'esecuzione di un gestore il segnale
che l'ha invocato viene bloccato, e abbiamo detto che possiamo ulteriormente
modificarlo con \func{sigprocmask}.
Resta quindi il problema di cosa succede alla maschera dei segnali quando si
-esce da un manipolatore usando questa funzione. Il comportamento dipende
+esce da un gestore usando questa funzione. Il comportamento dipende
dall'implementazione; in particolare BSD ripristina la maschera dei segnali
precedente l'invocazione, come per un normale ritorno, mentre System V no. Lo
standard POSIX.1 non specifica questo comportamento per \func{setjmp} e
\func{longjmp}.
+
+\subsection{I segnali real-time}
+\label{sec:sig_real_time}
+
+
+Lo standard POSIX.1b, nel definire una serie di nuove interfacce per i servizi
+real-time, ha introdotto una estensione del modello classico dei segnali che
+presenta dei significativi miglioramenti,\footnote{questa estensione è stata
+ 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}
+\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]
+
+ 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}
+
+
+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:
+
+\begin{itemize*}
+\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
+ segnale per ogni occorrenza dell'evento che lo genera.
+\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
+ \type{siginfo\_t} accessibile tramite gestori di tipo
+ \var{sa\_sigaction}.
+\end{itemize*}
+
+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 \macro{SIGRTMIN}
+e \macro{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
+l'esecuzione di un gestore di un segnale a priorità più alta; la loro azione
+predefinita è quella di terminare il programma. I segnali ordinari hanno
+tutti la stessa priorità, che è più alta di quella di qualunque segnale
+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 \type{siginfo\_t} una struttura
+\type{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.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+union sigval {
+ int sival_int;
+ void *sival_ptr;
+}
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \type{sigval}, usata dai segnali real time per
+ restituire dati al gestore.}
+ \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 \var{sigval}; per questo motivo lo standard ha previsto una nuova
+funzione, \func{sigqueue}, il cui prototipo è:
+\begin{prototype}{signal.h}
+ {int sigqueue(pid\_t pid, int signo, const union sigval 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[\macro{EAGAIN}] La coda è esarita, ci sono già \macro{SIGQUEUE\_MAX}
+ segnali in attesa si consegna.
+ \item[\macro{EPERM}] Non si hanno privilegi appropriati per inviare il
+ segnale al processo specificato.
+ \item[\macro{ESRCH}] Il processo \param{pid} non esiste.
+ \item[\macro{EINVAL}] Si è specificato un valore non valido per
+ \param{signo}.
+ \end{errlist}
+ ed inoltre \macro{ENOMEM}.}
+\end{prototype}
+
+Il comportamento della funzione è analogo a quello di \func{kill}, ed i
+privilegi occorrenti ad inviare il segnale ad un determinato processo sono gli
+stessi; un valore nullo di \func{signo} permette di verificare le condizioni
+di errore senza inviare nessun segnale.
+
+Se il segnale è bloccato la funzione ritorna immediatamente, se si è
+installato un gestore con \macro{SA\_SIGINFO} e ci sono risorse
+disponibili, vale a dire che c'è posto nella coda\footnote{la profondità della
+ coda è indicata dalla costante \macro{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, \macro{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32.}, esso viene inserito
+e diventa pendente; una volta consegnato riporterà nel campo \var{si\_code} di
+\var{siginfo} il valore \macro{SI\_QUEUE} e il campo \var{si\_value} riceverà
+quanto inviato con \param{value}. Se invece si è installato un 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
+modo nel caso dei thread, in cui si possono usare i segnali real-time come
+meccanismi di comunicazione elementare; la prima di queste funzioni è
+\func{sigwait}, il cui prototipo è:
+\begin{prototype}{signal.h}
+ {int sigwait(const sigset\_t *set, int *sig)}
+
+ Attende che uno dei segnali specificati in \param{set} sia pendente.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\macro{EINTR}] La funzione è stata interrotta.
+ \item[\macro{EINVAL}] Si è specificato un valore non valido per
+ \param{set}.
+ \end{errlist}
+ ed inoltre \macro{EFAULT}.}
+\end{prototype}
+
+La funzione estrae dall'insieme dei segnali pendenti uno qualunque dei segnali
+specificati da \param{set}, il cui valore viene restituito in \param{sig}. Se
+sono pendenti più segnali, viene estratto quello a priorità più alta (cioè con
+il numero più basso). Se, nel caso di segnali real-time, c'è più di un segnale
+pendente, ne verrà estratto solo uno. Una volta estratto il segnale non verrà
+più consegnato, e se era in una coda il suo posto sarà liberato. Se non c'è
+nessun segnale pendente il processo viene bloccato fintanto che non ne arriva
+uno.
+
+Per un funzionamento corretto la funzione richiede che alla sua chiamata i
+segnali di \param{set} siano bloccati. In caso contrario si avrebbe un
+conflitto con gli eventuali gestori: pertanto non si deve utilizzare per
+lo stesso segnale questa funzione e \func{sigaction}. Se questo non avviene il
+comportamento del sistema è indeterminato: il segnale può sia essere
+consegnato che essere ricevuto da \func{sigwait}, il tutto in maniera non
+prevedibile.
+
+Lo standard POSIX.1b definisce altre due funzioni, anch'esse usate
+prevalentemente con i thread; \func{sigwaitinfo} e \func{sigtimedwait}, i
+relativi prototipi sono:
+\begin{functions}
+ \headdecl{signal.h}
+
+ \funcdecl{int sigwaitinfo(const sigset\_t *set, siginfo\_t *info)}
+
+ Analoga a \func{sigwait}, ma riceve anche le informazioni associate al
+ segnale in \param{info}.
+
+ \funcdecl{int sigtimedwait(const sigset\_t *set, siginfo\_t *value, const
+ struct timespec *info)}
+
+ Analoga a \func{sigwaitinfo}, con un la possibilità di specificare un
+ timeout in \param{timeout}.
+
+
+ \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei valori già visti per
+ \func{sigwait}, ai quali si aggiunge, per \func{sigtimedwait}:
+ \begin{errlist}
+ \item[\macro{EAGAIN}] Si è superato il timeout senza che un segnale atteso
+ fosse emmesso.
+ \end{errlist}
+}
+\end{functions}
+
+Entrambe le funzioni sono estensioni di \func{sigwait}. La prima permette di
+ricevere, oltre al numero del segnale, anche le informazioni ad esso associate
+tramite \param{info}; in particolare viene restituito il numero del segnale
+nel campo \var{si\_signo}, la sua causa in \var{si\_code}, e se il segnale è
+stato immesso sulla coda con \func{sigqueue}, il valore di ritorno ad esso
+associato viene riportato in \var{si\_value}, che altrimenti è indefinito.
+
+La seconda è identica alla prima ma in più permette di specificare un timeout,
+scaduto il quale ritornerà con un errore. Se si specifica un puntatore nullo
+il comportamento sarà identico a \func{sigwaitinfo}, se si specifica un tempo
+di timeout nullo, e non ci sono sengali pendenti la funzione ritornerà
+immediatamente; in questo modo si può eliminare un segnale dalla coda senza
+dover essere bloccati qualora esso non sia presente.
+
+
+L'uso di queste funzioni è principalmente associato alla gestione dei segnali
+com i thread. In genere esse vengono chiamate dal thread incaricato della
+gestione, che al ritorno della funzione esegue il codice che usualmente
+sarebbe messo nel gestore, per poi ripetere la chiamata per mettersi in attesa
+del segnale successivo. Questo ovviamente comporta che non devono essere
+installati gestori, che solo il thread di gestione deve usare \func{sigwait} e
+che, per evitare che venga eseguita l'azione predefinita, i segnali gestiti in
+questa maniera devono essere mascherati per tutti i thread, compreso quello
+dedicato alla gestione, che potrebbe riceverlo fra due chiamate successive.
+
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
projects / gapil.git / blobdiff