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
+eccezionali (come errori di accesso, eccezioni aritmetiche, ecc.) ma possono
anche essere usati come forma elementare di comunicazione fra processi (ad
esempio vengono usati per il controllo di sessione), per notificare eventi
(come la terminazione di un processo figlio), ecc.
In questo capitolo esamineremo i vari aspetti della gestione dei segnali,
partendo da una introduzione relativa ai concetti base con cui essi vengono
realizzati, per poi affrontarne la classificazione a secondo di uso e modalità
-di generazione fino ad esaminare in dettaglio funzioni e le metodologie di
+di generazione fino ad esaminare in dettaglio le funzioni e le metodologie di
gestione avanzate e le estensioni fatte all'interfaccia classica nelle nuovi
versioni dello standard POSIX.
\begin{itemize*}
\item un errore del programma, come una divisione per zero o un tentativo di
- accesso alla memoria fuori dai limiti validi.
-\item la terminazione di un processo figlio.
-\item la scadenza di un timer o di un allarme.
+ accesso alla memoria fuori dai limiti validi;
+\item la terminazione di un processo figlio;
+\item la scadenza di un timer o di un allarme;
\item il tentativo di effettuare un'operazione di input/output che non può
- essere eseguita.
+ essere eseguita;
\item una richiesta dell'utente di terminare o fermare il programma. In genere
si realizza attraverso un segnale mandato dalla shell in corrispondenza
della pressione di tasti del terminale come \code{C-c} o
- \code{C-z}.\footnote{indichiamo con \code{C-x} la pressione simultanea al
+ \code{C-z};\footnote{indichiamo con \code{C-x} la pressione simultanea al
tasto \code{x} del tasto control (ctrl in molte tastiere).}
\item l'esecuzione di una \func{kill} o di una \func{raise} da parte del
- processo stesso o di un'altro (solo nel caso della \func{kill}).
+ processo stesso o di un altro (solo nel caso della \func{kill}).
\end{itemize*}
Ciascuno di questi eventi (compresi gli ultimi due che pure sono controllati
dall'utente o da un altro processo) comporta l'intervento diretto da parte del
-kernel che causa la generazione un particolare tipo di segnale.
+kernel che causa la generazione di un particolare tipo di segnale.
Quando un processo riceve un segnale, invece del normale corso del programma,
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'inglese \textit{signal handler}) che può essere stata specificata
dall'utente (nel qual caso si dice che si \textsl{intercetta} il segnale).
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 gestore non sono operazioni atomiche, e
-sono sempre possibili delle race condition\index{\textit{race~condition}}
+sono sempre possibili delle \textit{race condition}\itindex{race~condition}
(sull'argomento vedi quanto detto in sez.~\ref{sec:proc_multi_prog}).
-Un'altro problema è che in questa semantica non esiste un modo per bloccare i
+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
segnale, ma non è possibile istruire il sistema a non fare nulla in occasione
di un segnale, pur mantenendo memoria del fatto che è avvenuto.
Nella semantica \textsl{affidabile} (quella utilizzata da Linux e da ogni Unix
-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 impostando l'apposito
-campo della \struct{task\_struct} del processo nella process table (si veda
-fig.~\ref{fig:proc_task_struct}).
+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 impostando l'apposito campo della
+\struct{task\_struct} del processo nella \itindex{process~table}
+\textit{process table} (si veda fig.~\ref{fig:proc_task_struct}).
Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
\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\index{\textit{scheduler}} quando,
+procedura viene effettuata dallo scheduler\itindex{scheduler} quando,
riprendendo l'esecuzione del processo in questione, verifica la presenza del
segnale nella \struct{task\_struct} e mette in esecuzione il gestore.
Un errore significa che un programma ha fatto qualcosa di sbagliato e non può
continuare ad essere eseguito. Non tutti gli errori causano dei segnali, in
-genere la condizione di errore più comune comporta la restituzione di un
-codice di errore da parte di una funzione di libreria, sono gli errori che
-possono avvenire ovunque in un programma che causano l'emissione di un
-segnale, come le divisioni per zero o l'uso di indirizzi di memoria non validi.
+genere le condizioni di errore più comuni comportano la restituzione di un
+codice di errore da parte di una funzione di libreria; sono gli errori che
+possono avvenire nella esecuzione delle istruzioni di un programma che causano
+l'emissione di un segnale, come le divisioni per zero o l'uso di indirizzi di
+memoria non validi.
Un evento esterno ha in genere a che fare con l'I/O o con altri processi;
esempi di segnali di questo tipo sono quelli legati all'arrivo di dati di
Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
avviene non appena questo viene rimesso in esecuzione dallo
-scheduler\index{\textit{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}
+scheduler\itindex{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 tenga presente però che i segnali \textsl{pendenti} non si
accodano, alla generazione infatti il kernel marca un flag nella
Si ricordi però che se l'azione specificata per un segnale è quella di essere
ignorato questo sarà scartato immediatamente al momento della sua generazione,
e questo anche se in quel momento il segnale è bloccato (perché bloccare su un
-segnale significa bloccarne è la notifica). Per questo motivo un segnale,
+segnale significa bloccarne la notifica). Per questo motivo un segnale,
fintanto che viene ignorato, non sarà mai notificato, anche se prima è stato
bloccato ed in seguito si è specificata una azione diversa (nel qual caso solo
i segnali successivi alla nuova specificazione saranno notificati).
una delle tre possibilità seguenti:
\begin{itemize*}
-\item ignorare il segnale.
-\item catturare il segnale, ed utilizzare il gestore specificato.
+\item ignorare il 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 sez.~\ref{sec:sig_signal} e
-sez.~\ref{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 gestore di un segnale, quest'ultimo
-venga automaticamente bloccato (così si possono evitare race
-condition\index{\textit{race~condition}}).
+sez.~\ref{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 gestore di un segnale, quest'ultimo venga
+automaticamente bloccato (così si possono evitare \textit{race
+ condition}\itindex{race~condition}).
Nel caso non sia stata specificata un'azione, viene utilizzata l'azione
standard che (come vedremo in sez.~\ref{sec:sig_standard}) è propria di ciascun
processo, ma alcuni segnali che rappresentano eventi innocui vengono ignorati.
Quando un segnale termina un processo, il padre può determinare la causa della
-terminazione esaminando il codice di stato riportato delle funzioni
+terminazione esaminando il codice di stato riportato dalle funzioni
\func{wait} e \func{waitpid} (vedi sez.~\ref{sec:proc_wait}); questo è il modo
in cui la shell determina i motivi della terminazione di un programma e scrive
un eventuale messaggio di errore.
I segnali che rappresentano errori del programma (divisione per zero o
violazioni di accesso) hanno anche la caratteristica di scrivere un file di
-\textit{core dump} che registra lo stato del processo (ed in particolare della
-memoria e dello stack) prima della terminazione. Questo può essere esaminato
-in seguito con un debugger per investigare sulla causa dell'errore. Lo stesso
-avviene se i suddetti segnale vengono generati con una \func{kill}.
+\itindex{core~dump}\textit{core dump} che registra lo stato del processo (ed
+in particolare della memoria e dello \itindex{stack} stack) prima della
+terminazione. Questo può essere esaminato in seguito con un debugger per
+investigare sulla causa dell'errore. Lo stesso avviene se i suddetti segnali
+vengono generati con una \func{kill}.
\section{La classificazione dei segnali}
Ciascun segnale è identificato rispetto al sistema da un numero, ma l'uso
diretto di questo numero da parte dei programmi è da evitare, in quanto esso
-può variare a seconda dell'implementazione del sistema, e nel caso si Linux,
+può variare a seconda dell'implementazione del sistema, e nel caso di Linux,
anche a seconda dell'architettura hardware.
Per questo motivo ad ogni segnale viene associato un nome, definendo con una
macro di preprocessore una costante uguale al suddetto numero. Sono questi
In alcuni casi alla terminazione del processo è associata la creazione di un
file (posto nella directory corrente del processo e chiamato \file{core}) su
cui viene salvata un'immagine della memoria del processo (il cosiddetto
-\textit{core dump}), che può essere usata da un debugger per esaminare lo
-stato dello stack e delle variabili al momento della ricezione del segnale.
+\itindex{core~dump}\textit{core dump}), che può essere usata da un debugger
+per esaminare lo stato dello \itindex{stack} stack e delle variabili al
+momento della ricezione del segnale.
\begin{table}[htb]
\footnotesize
\end{table}
La descrizione dettagliata del significato dei vari segnali, raggruppati per
-tipologia, verrà affrontate nei paragrafi successivi.
+tipologia, verrà affrontata nei paragrafi successivi.
\subsection{Segnali di errore di programma}
\label{sec:sig_prog_error}
Questi segnali sono generati quando il sistema, o in certi casi direttamente
-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.
+l'hardware (come per i \itindex{page~fault}\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 le impostazioni della
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
-dell'errore, che il debugger può usare per ricostruire lo stato del programma
-al momento della terminazione.
-
-Questi segnali sono:
+la registrazione su disco di un file di \itindex{core~dump}\textit{core dump}
+che viene scritto in un file \file{core} nella directory corrente del processo
+al momento dell'errore, che il debugger può usare per ricostruire lo stato del
+programma al momento della terminazione. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome
derivi da \textit{floating point exception} si applica a tutti gli errori
- aritmetici compresa la divisione per zero e l'overflow.
-
- Se il gestore ritorna il comportamento del processo è indefinito, ed
- ignorare questo segnale può condurre ad un ciclo infinito.
+ aritmetici compresa la divisione per zero e l'overflow. 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
% molte diverse eccezioni che \texttt{SIGFPE} non distingue, mentre lo
% standard IEEE per le operazioni in virgola mobile definisce varie eccezioni
% aritmetiche e richiede che esse siano notificate.
+% TODO trovare altre info su SIGFPE e trattare la notifica delle eccezioni
\item[\const{SIGILL}] Il nome deriva da \textit{illegal instruction},
significa che il programma sta cercando di eseguire una istruzione
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
- gestore. Se il gestore ritorna il comportamento del processo è
- indefinito.
+ una variabile locale, andando a corrompere lo \itindex{stack} stack. Lo
+ stesso segnale viene generato in caso di overflow dello \itindex{stack}
+ stack o di problemi nell'esecuzione di un gestore. Se il gestore ritorna il
+ comportamento del processo è indefinito.
\item[\const{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
ritorna il comportamento del processo è indefinito.
È tipico ottenere questo segnale dereferenziando un puntatore nullo o non
- inizializzato leggendo al di la della fine di un vettore.
+ inizializzato leggendo al di là della fine di un vettore.
\item[\const{SIGBUS}] Il nome deriva da \textit{bus error}. Come
\const{SIGSEGV} questo è un segnale che viene generato di solito quando si
dereferenzia un puntatore non inizializzato, la differenza è che
\const{SIGSEGV} indica un accesso non permesso su un indirizzo esistente
- (tipo fuori dallo heap o dallo stack), mentre \const{SIGBUS} indica
- l'accesso ad un indirizzo non valido, come nel caso di un puntatore non
- allineato.
+ (tipo fuori dallo heap o dallo \itindex{stack} stack), mentre \const{SIGBUS}
+ indica l'accesso ad un indirizzo non valido, come nel caso di un puntatore
+ non allineato.
\item[\const{SIGABRT}] Il nome deriva da \textit{abort}. Il segnale indica che
il programma stesso ha rilevato un errore che viene riportato chiamando la
funzione \func{abort} che genera questo segnale.
\item[\const{SIGTRAP}] È il segnale generato da un'istruzione di breakpoint o
dall'attivazione del tracciamento per il processo. È usato dai programmi per
- il debugging e se un programma normale non dovrebbe ricevere questo segnale.
+ il debugging e un programma normale non dovrebbe ricevere questo segnale.
\item[\const{SIGSYS}] Sta ad indicare che si è eseguita una istruzione che
richiede l'esecuzione di una system call, ma si è fornito un codice
sbagliato per quest'ultima.
interruzione per il programma. È quello che viene generato di default dal
comando \cmd{kill} o dall'invio sul terminale del carattere di controllo
INTR (interrupt, generato dalla sequenza \cmd{C-c}).
-\item[\const{SIGQUIT}] È analogo a \const{SIGINT} con la differenze che è
- controllato da un'altro carattere di controllo, QUIT, corrispondente alla
+\item[\const{SIGQUIT}] È analogo a \const{SIGINT} con la differenza che è
+ controllato da un altro carattere di controllo, QUIT, corrispondente alla
sequenza \verb|C-\|. A differenza del precedente l'azione predefinita, oltre
- alla terminazione del processo, comporta anche la creazione di un core dump.
+ alla terminazione del processo, comporta anche la creazione di un
+ \itindex{core~dump}\textit{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
Questi segnali operano in congiunzione con le funzioni di I/O asincrono. Per
questo occorre comunque usare \func{fcntl} per abilitare un file descriptor a
-generare questi segnali.
-
-L'azione predefinita è di essere ignorati. Questi segnali sono:
+generare questi segnali. L'azione predefinita è di essere ignorati. Questi
+segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{SIGIO}] Questo segnale viene inviato quando un file descriptor è
pronto per eseguire dell'input/output. In molti sistemi solo i
\label{sec:sig_job_control}
Questi sono i segnali usati dal controllo delle sessioni e dei processi, il
-loro uso è specifico e viene trattato in maniera specifica nelle sezioni in
-cui si trattano gli argomenti relativi. Questi segnali sono:
+loro uso è specializzato e viene trattato in maniera specifica nelle sezioni
+in cui si trattano gli argomenti relativi. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{SIGCHLD}] Questo è il segnale mandato al processo padre quando un
figlio termina o viene fermato. L'azione predefinita è di ignorare il
Questi segnali sono usati per riportare al programma errori generati da
operazioni da lui eseguite; non indicano errori del programma quanto errori
che impediscono il completamento dell'esecuzione dovute all'interazione con il
-resto del sistema.
-
-L'azione predefinita di questi segnali è di terminare il processo, questi
-segnali sono:
+resto del sistema. L'azione predefinita di questi segnali è di terminare il
+processo, questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{SIGPIPE}] Sta per \textit{Broken pipe}. Se si usano delle pipe,
(o delle FIFO o dei socket) è necessario, prima che un processo inizi a
- scrivere su una di esse, che un'altro l'abbia aperta in lettura (si veda
+ scrivere su una di esse, che un altro l'abbia aperta in lettura (si veda
sez.~\ref{sec:ipc_pipes}). Se il processo in lettura non è partito o è
terminato inavvertitamente alla scrittura sulla pipe il kernel genera questo
segnale. Se il segnale è bloccato, intercettato o ignorato la chiamata che
lo ha causato fallisce, restituendo l'errore \errcode{EPIPE}.
-\item[\const{SIGLOST}] Sta per \textit{Resource lost}. Viene generato quando
- c'è un advisory lock su un file NFS, ed il server riparte dimenticando la
- situazione precedente.
+\item[\const{SIGLOST}] Sta per \textit{Resource lost}. Tradizionalmente è il
+ segnale che viene generato quando si perde un advisory lock su un file su
+ NFS perché il server NFS è stato riavviato. Il progetto GNU lo utilizza per
+ indicare ad un client il crollo inaspettato di un server. In Linux è
+ definito come sinonimo di \const{SIGIO}.\footnote{ed è segnalato come BUG
+ nella pagina di manuale.}
\item[\const{SIGXCPU}] Sta per \textit{CPU time limit exceeded}. Questo
segnale è generato quando un processo eccede il limite impostato per il
tempo di CPU disponibile, vedi sez.~\ref{sec:sys_resource_limit}.
\subsection{Ulteriori segnali}
\label{sec:sig_misc_sig}
-Raccogliamo qui infine usa serie di segnali che hanno scopi differenti non
+Raccogliamo qui infine una serie di segnali che hanno scopi differenti non
classificabili in maniera omogenea. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{SIGUSR1}] Insieme a \const{SIGUSR2} è un segnale a disposizione
\end{prototype}
Una modalità alternativa per utilizzare le descrizioni restituite da
-\func{strsignal} e \func{psignal} è quello di fare usare la variabile
+\func{strsignal} e \func{psignal} è quello di usare la variabile
\var{sys\_siglist}, che è definita in \file{signal.h} e può essere acceduta
con la dichiarazione:
\includecodesnip{listati/siglist.c}
-l'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
+
+L'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
indicizzate per numero di segnale, per cui una chiamata del tipo di \code{char
*decr = strsignal(SIGINT)} può essere sostituita dall'equivalente \code{char
*decr = sys\_siglist[SIGINT]}.
effettuata all'interno del normale flusso di esecuzione dello stesso, ma è
delegata appunto agli eventuali gestori che si sono installati.
-In questa sezione vedremo come si effettua gestione dei segnali, a partire
+In questa sezione vedremo come si effettua la gestione dei segnali, a partire
dalla loro interazione con le system call, passando per le varie funzioni che
-permettono di installare i gestori e controllare le reazioni di un
-processo alla loro occorrenza.
+permettono di installare i gestori e controllare le reazioni di un processo
+alla loro occorrenza.
-\subsection{Il comportamento generale del sistema.}
+\subsection{Il comportamento generale del sistema}
\label{sec:sig_gen_beha}
Abbiamo già trattato in sez.~\ref{sec:sig_intro} le modalità con cui il sistema
\begin{itemize*}
\item la lettura da file che possono bloccarsi in attesa di dati non ancora
presenti (come per certi file di dispositivo\index{file!di~dispositivo}, i
- socket\index{socket} o le pipe).
+ socket\index{socket} o le pipe);
\item la scrittura sugli stessi file, nel caso in cui dati non possano essere
- accettati immediatamente.
+ accettati immediatamente (di nuovo comune per i socket);
\item l'apertura di un file di dispositivo che richiede operazioni non
- immediate per una risposta.
+ immediate per una risposta (ad esempio l'apertura di un nastro che deve
+ essere riavvolto);
\item le operazioni eseguite con \func{ioctl} che non è detto possano essere
- eseguite immediatamente.
+ eseguite immediatamente;
\item le funzioni di intercomunicazione che si bloccano in attesa di risposte
- da altri processi.
+ da altri processi;
\item la funzione \func{pause} (usata appunto per attendere l'arrivo di un
- segnale).
+ segnale);
\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 gestore
-sia ritornato. La scelta originaria dei primi Unix era quella di far ritornare
+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 \errcode{EINTR}. Questa è a
tutt'oggi una scelta corrente, ma comporta che i programmi che usano dei
-gestori controllino lo stato di uscita delle funzioni per ripeterne la
-chiamata qualora l'errore fosse questo.
+gestori controllino lo stato di uscita delle funzioni che eseguono una system
+call lenta per ripeterne la chiamata qualora l'errore fosse questo.
Dimenticarsi di richiamare una system call interrotta da un segnale è un
errore comune, tanto che le \acr{glibc} provvedono una macro
\label{sec:sig_signal}
L'interfaccia più semplice per la gestione dei segnali è costituita dalla
-funzione \funcd{signal} che è definita fin dallo standard ANSI C. Quest'ultimo
-però non considera sistemi multitasking, per cui la definizione è tanto vaga
-da essere del tutto inutile in un sistema Unix; è questo il motivo per cui
-ogni implementazione successiva ne ha modificato e ridefinito il
+funzione \funcd{signal} che è definita fin dallo standard ANSI C.
+Quest'ultimo però non considera sistemi multitasking, per cui la definizione è
+tanto vaga da essere del tutto inutile in un sistema Unix; è questo il motivo
+per cui ogni implementazione successiva ne ha modificato e ridefinito il
comportamento, pur mantenendone immutato il prototipo\footnote{in realtà in
alcune vecchie implementazioni (SVr4 e 4.3+BSD in particolare) vengono usati
- alcuni parametri aggiuntivi per definire il comportamento della funzione,
+ alcuni argomenti aggiuntivi per definire il comportamento della funzione,
vedremo in sez.~\ref{sec:sig_sigaction} che questo è possibile usando la
funzione \func{sigaction}.} che è:
\begin{prototype}{signal.h}
direttamente con una delle costanti definite in sez.~\ref{sec:sig_standard}. Il
gestore \param{handler} invece, oltre all'indirizzo della funzione da chiamare
all'occorrenza del segnale, può assumere anche i due valori costanti
-\const{SIG\_IGN} con cui si dice ignorare il segnale e \const{SIG\_DFL} per
+\const{SIG\_IGN} con cui si dice di ignorare il segnale e \const{SIG\_DFL} per
reinstallare l'azione predefinita.\footnote{si ricordi però che i due segnali
- \const{SIGKILL} e \const{SIGSTOP} non possono essere ignorati né
+ \const{SIGKILL} e \const{SIGSTOP} non possono essere né ignorati né
intercettati; l'uso di \const{SIG\_IGN} per questi segnali non ha alcun
effetto.}
\begin{prototype}{signal.h}{int raise(int sig)}
Invia il segnale \param{sig} al processo corrente.
- \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
+ \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
errore, il solo errore restituito è \errval{EINVAL} qualora si sia
specificato un numero di segnale invalido.}
\end{prototype}
\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
+ \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
errore nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINVAL}] Il segnale specificato non esiste.
\code{kill(-pidgrp, signal)}; il suo prototipo è:
\begin{prototype}{signal.h}{int killpg(pid\_t pidgrp, int signal)}
- Invia il segnale \param{signal} al process group \param{pidgrp}.
- \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ Invia il segnale \param{signal} al \itindex{process~group} \textit{process
+ group} \param{pidgrp}.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
errore, gli errori sono gli stessi di \func{kill}.}
\end{prototype}
-\noindent e che permette di inviare un segnale a tutto un \textit{process
- group} (vedi sez.~\ref{sec:sess_proc_group}).
+\noindent e permette di inviare un segnale a tutto un \itindex{process~group}
+\textit{process group} (vedi sez.~\ref{sec:sess_proc_group}).
\begin{table}[htb]
\footnotesize
\hline
\hline
$>0$ & il segnale è mandato al processo con il \acr{pid} indicato.\\
- 0 & il segnale è mandato ad ogni processo del \textit{process group}
- del chiamante.\\
+ 0 & il segnale è mandato ad ogni processo del \itindex{process~group}
+ \textit{process group} del chiamante.\\
$-1$ & il segnale è mandato ad ogni processo (eccetto \cmd{init}).\\
- $<-1$ & il segnale è mandato ad ogni processo del process group
- $|\code{pid}|$.\\
+ $<-1$ & il segnale è mandato ad ogni processo del \textit{process group}
+ \itindex{process~group} $|\code{pid}|$.\\
\hline
\end{tabular}
\caption{Valori dell'argomento \param{pid} per la funzione
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 implementazione di
+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.
questo può essere usato per cancellare una programmazione precedente.
La funzione inoltre ritorna il numero di secondi rimanenti all'invio
-dell'allarme precedentemente programmato, in modo che sia possibile
-controllare se non si cancella un precedente allarme ed eventualmente
-predisporre le opportune misure per gestire il caso di necessità di più
-interruzioni.
+dell'allarme programmato in precedenza. In questo modo è possibile controllare
+se non si è cancellato un precedente allarme e predisporre eventuali misure
+che permettano di gestire il caso in cui servono più interruzioni.
In sez.~\ref{sec:sys_unix_time} abbiamo visto che ad ogni processo sono
associati tre tempi diversi: il \textit{clock time}, l'\textit{user time} ed
\begin{itemize}
\item un \textit{real-time timer} che calcola il tempo reale trascorso (che
corrisponde al \textit{clock time}). La scadenza di questo timer provoca
- l'emissione di \const{SIGALRM}.
+ l'emissione di \const{SIGALRM};
\item un \textit{virtual timer} che calcola il tempo di processore usato dal
processo in user space (che corrisponde all'\textit{user time}). La scadenza
- di questo timer provoca l'emissione di \const{SIGVTALRM}.
+ di questo timer provoca l'emissione di \const{SIGVTALRM};
\item un \textit{profiling timer} che calcola la somma dei tempi di processore
utilizzati direttamente dal processo in user space, e dal kernel nelle
system call ad esso relative (che corrisponde a quello che in
itimerval *value, struct itimerval *ovalue)}
Predispone l'invio di un segnale di allarme alla scadenza dell'intervallo
- \param{value} sul timer specificato da \func{which}.
+ \param{value} sul timer specificato da \param{which}.
- \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ \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}
\begin{prototype}{sys/time.h}{int getitimer(int which, struct
itimerval *value)}
- Legge in \param{value} il valore del timer specificato da \func{which}.
+ 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
+ \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 parametri hanno lo stesso significato e formato di quelli di
+\noindent i cui argomenti hanno lo stesso significato e formato di quelli di
\func{setitimer}.
-L'ultima funzione che permette l'invio diretto di un segnale è \funcd{abort};
+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 \const{SIGABRT}. Il suo
prototipo è:
\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{at\_exit} e \func{on\_exit}.
+eventuali funzioni registrate con \func{atexit} e \func{on\_exit}.
\subsection{Le funzioni di pausa e attesa}
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
+ il relativo gestore è ritornato, nel qual caso restituisce $-1$ e
\var{errno} assumerà il valore \errval{EINTR}.}
\end{prototype}
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
+ \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}.}
\end{prototype}
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:
+ \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}
\item[\errcode{EINVAL}] si è specificato un numero di secondi negativo o un
numero di nanosecondi maggiore di 999.999.999.
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 \const{SIGALRM}. La funzione prende come parametri
+interferenze con l'uso di \const{SIGALRM}. La funzione prende come argomenti
delle strutture di tipo \struct{timespec}, la cui definizione è riportata in
fig.~\ref{fig:sys_timeval_struct}, che permettono di specificare un tempo con
una precisione (teorica) fino al nanosecondo.
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\index{\textit{scheduler}} e cioè un tempo che a seconda dei casi può
-arrivare fino a 1/\const{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/\const{HZ}.
+occorrerà almeno attendere il successivo giro di scheduler\itindex{scheduler}
+e cioè un tempo che a seconda dei casi può arrivare fino a 1/\const{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/\const{HZ}.
In realtà è possibile ottenere anche pause più precise del centesimo di
-secondo usando politiche di scheduling real time come \const{SCHED\_FIFO} o
+secondo usando politiche di scheduling real-time come \const{SCHED\_FIFO} o
\const{SCHED\_RR}; in tal caso infatti il meccanismo di scheduling ordinario
viene evitato, e si raggiungono pause fino ai 2~ms con precisioni del $\mu$s.
ed usa il nome di \const{SIGCLD} come sinonimo di \const{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 \const{SIGCHLD} il cui unico compito sia quello chiamare
+gestore per \const{SIGCHLD} il cui unico compito sia quello di chiamare
\func{waitpid} per completare la procedura di terminazione in modo da evitare
la formazione di zombie\index{zombie}.
gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione
di zombie\index{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
-% gestore per che è previsto ritornare,
-
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
\end{minipage}
\normalsize
\caption{Codice di una funzione generica di gestione per il segnale
- \texttt{SIGCHLD}.}
+ \texttt{SIGCHLD}.}
\label{fig:sig_sigchld_handl}
\end{figure}
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 12-13}) con il salvare lo stato corrente di
+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 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}.
+(\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}.
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
+(\texttt{\small 9--15}). Il ciclo è necessario a causa di una caratteristica
fondamentale della gestione dei segnali: abbiamo già accennato come fra la
generazione di un segnale e l'esecuzione del gestore possa passare un certo
lasso di tempo e niente ci assicura che il gestore venga eseguito prima della
che molti processi figli terminino in rapida successione. Esso inoltre si
presenta tutte le volte che un segnale viene bloccato: per quanti siano i
segnali emessi durante il periodo di blocco, una volta che quest'ultimo sarà
-rimosso sarà recapitato un solo segnale.
+rimosso verrà recapitato un solo segnale.
Allora, nel caso della terminazione dei processi figli, se si chiamasse
\func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un
\section{Gestione avanzata}
\label{sec:sig_control}
-Le funzioni esaminate finora fanno riferimento ad alle modalità più elementari
+Le funzioni esaminate finora fanno riferimento 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\index{\textit{race~condition}} che i segnali possono generare e alla
+considerazione le tematiche più complesse, collegate alle varie \textit{race
+ condition}\itindex{race~condition} che i segnali possono generare e alla
natura asincrona degli stessi.
Affronteremo queste problematiche in questa sezione, partendo da un esempio
fig.~\ref{fig:sig_sleep_wrong}.
Dato che è nostra intenzione utilizzare \const{SIGALRM} il primo passo della
-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 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
+nostra implementazione 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
+ 18-20}) fino alla sua ricezione. Al ritorno di \func{pause}, causato dal
+ritorno del gestore (\texttt{\small 1-9}), si ripristina il gestore originario
+(\texttt{\small 21-22}) restituendo l'eventuale tempo rimanente
+(\texttt{\small 23-24}) che potrà essere diverso da zero qualora
l'interruzione di \func{pause} venisse causata da un altro segnale.
\begin{figure}[!htb]
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\index{\textit{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
+presenta una pericolosa \textit{race condition}\itindex{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 di quest'ultima, cosicché essa
sarebbe eseguita dopo l'arrivo di \const{SIGALRM}. In questo caso ci si
-troverebbe di fronte ad un deadlock\index{\textit{deadlock}}, in quanto
-\func{pause} non verrebbe mai più interrotta (se non in caso di un altro
-segnale).
+troverebbe di fronte ad un deadlock\itindex{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 sez.~\ref{sec:proc_longjmp}) per
\label{fig:sig_sleep_incomplete}
\end{figure}
-In questo caso il gestore (\texttt{\small 18-26}) non ritorna come in
-fig.~\ref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 24}) per
+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
segnale, e prendere le relative azioni conseguenti (\texttt{\small 6-11}).
Questo è il tipico esempio di caso, già citato in
-sez.~\ref{sec:proc_race_cond}, in cui si genera una race condition
-\index{\textit{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.
+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
+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
\subsection{Gli \textsl{insiemi di segnali} o \textit{signal set}}
\label{sec:sig_sigset}
-\index{\textit{signal~set}|(}
+\itindbeg{signal~set}
+
Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali
originarie, nate con la semantica inaffidabile, hanno dei limiti non
superabili; in particolare non è prevista nessuna funzione che permetta di
-gestire 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 ottenete un controllo molto più dettagliato. In particolare lo
+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
standard ha introdotto un nuovo tipo di dato \type{sigset\_t}, che permette di
rappresentare un \textsl{insieme di segnali} (un \textit{signal set}, come
-viene usualmente chiamato), che è il tipo di dato che viene usato per gestire
-il blocco dei segnali.
+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 si 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:
+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}
\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}
+ 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}
insieme completo ottenuto con \func{sigfillset}. Infine \func{sigismember}
permette di verificare la presenza di uno specifico segnale in un
insieme.
-\index{\textit{signal~set}|)}
+\itindend{signal~set}
\subsection{La funzione \func{sigaction}}
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 sostanzialemente lo stesso uso di \func{signal},
+\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
Installa una nuova azione per il segnale \param{signum}.
- \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
+ \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EINVAL}] Si è specificato un numero di segnale invalido o si è
\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\_ONSTACK} & Stabilisce l'uso di uno stack alternativo per
- l'esecuzione del gestore (vedi
+ \const{SA\_ONSTACK} & Stabilisce l'uso di uno \itindex{stack} stack
+ alternativo per l'esecuzione del gestore (vedi
sez.~\ref{sec:sig_specific_features}).\\
\hline
\end{tabular}
\label{tab:sig_sa_flag}
\end{table}
-Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction}
-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 sez.~\ref{sec:sig_real_time}). In precedenza era possibile
- ottenere alcune informazioni addizionali usando \var{sa\_handler} con un
- secondo parametro addizionale di tipo \var{sigcontext}, che adesso è
- deprecato.} di utilizzare due forme diverse di gestore, da specificare, a
-seconda dell'uso o meno del flag \const{SA\_SIGINFO}, rispettivamente
-attraverso i campi \var{sa\_sigaction} o \var{sa\_handler},\footnote{i due
- tipi devono essere usati in maniera alternativa, in certe implementazioni
- questi campi vengono addirittura definiti come \ctyp{union}.} Quest'ultima
-è quella classica usata anche con \func{signal}, mentre la prima permette di
-usare un gestore più complesso, in grado di ricevere informazioni più
-dettagliate dal sistema, attraverso la struttura \struct{siginfo\_t},
-riportata in fig.~\ref{fig:sig_siginfo_t}.
+% TODO con il 2.6 sono stati aggiunti SA_NOCLDWAIT e altro, documentare
+
+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
+ con l'introduzione dei segnali real-time (vedi
+ sez.~\ref{sec:sig_real_time}); in precedenza era possibile ottenere alcune
+ informazioni addizionali usando \var{sa\_handler} con un secondo parametro
+ addizionale di tipo \var{sigcontext}, che adesso è deprecato.} da
+specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO},
+rispettivamente attraverso i campi \var{sa\_sigaction} o
+\var{sa\_handler},\footnote{i due tipi devono essere usati in maniera
+ alternativa, in certe implementazioni questi campi vengono addirittura
+ definiti come \ctyp{union}.} Quest'ultima è quella classica usata anche con
+\func{signal}, mentre la prima permette di usare un gestore più complesso, in
+grado di ricevere informazioni più dettagliate dal sistema, attraverso la
+struttura \struct{siginfo\_t}, riportata in fig.~\ref{fig:sig_siginfo_t}.
\begin{figure}[!htb]
\footnotesize \centering
segnali 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, \const{SIGILL}, \const{SIGFPE},
-\const{SIGSEGV} e \const{SIGBUS} avvalorano \var{si\_addr} con l'indirizzo cui
-è avvenuto l'errore, \const{SIGIO} (vedi sez.~\ref{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\index{socket}.
+\const{SIGSEGV} e \const{SIGBUS} avvalorano \var{si\_addr} con l'indirizzo in
+cui è avvenuto l'errore, \const{SIGIO} (vedi
+sez.~\ref{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\index{socket}.
Benché sia possibile usare nello stesso programma sia \func{sigaction} che
\func{signal} occorre molta attenzione, in quanto le due funzioni possono
\includecodesample{listati/Signal.c}
\end{minipage}
\normalsize
- \caption{La funzione \funcd{Signal}, equivalente a \func{signal}, definita
+ \caption{La funzione \func{Signal}, equivalente a \func{signal}, definita
attraverso \func{sigaction}.}
\label{fig:sig_Signal_code}
\end{figure}
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 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
+ un nuovo frame nello \itindex{stack} 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.}
-
-
\subsection{La gestione della \textsl{maschera dei segnali} o
\textit{signal mask}}
\label{sec:sig_sigmask}
-\index{\textit{signal mask}|(}
+\itindbeg{signal~mask}
Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like
-permettono si bloccare temporaneamente (o di eliminare completamente,
+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
è 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 eseguiti senza interruzioni.
+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
Cambia la \textsl{maschera dei segnali} del processo corrente.
- \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
+ \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EINVAL}] Si è specificato un numero di segnale invalido.
perduta alla conclusione del terminatore.
Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
-dei casi di race condition\index{\textit{race~condition}} restano aperte
+dei casi di \textit{race condition}\itindex{race~condition} restano aperte
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
Imposta la \textit{signal mask} specificata, mettendo in attesa il processo.
- \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
+ \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EINVAL}] Si è specificato un numero di segnale invalido.
Per evitare i problemi di interferenza con gli altri segnali in questo caso
non si è usato l'approccio di fig.~\ref{fig:sig_sleep_incomplete} evitando
-l'uso di \func{longjmp}. Come in precedenza il gestore (\texttt{\small 35-37})
+l'uso di \func{longjmp}. Come in precedenza il gestore (\texttt{\small 27-30})
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
+La prima parte della funzione (\texttt{\small 6-10}) provvede ad installare
l'opportuno gestore per \const{SIGALRM}, salvando quello originario, che
-sarà ripristinato alla conclusione della stessa (\texttt{\small 28}); il passo
-successivo è quello di bloccare \const{SIGALRM} (\texttt{\small 17-19}) per
+sarà ripristinato alla conclusione della stessa (\texttt{\small 23}); il passo
+successivo è quello di bloccare \const{SIGALRM} (\texttt{\small 11-14}) per
evitare che esso possa essere ricevuto dal processo fra l'esecuzione di
-\func{alarm} (\texttt{\small 21}) e la sospensione dello stesso. Nel fare
+\func{alarm} (\texttt{\small 16}) e la sospensione dello stesso. Nel fare
questo si salva la maschera corrente dei segnali, che sarà ripristinata alla
-fine (\texttt{\small 27}), e al contempo si prepara la maschera dei segnali
+fine (\texttt{\small 22}), e al contempo si prepara la maschera dei segnali
\var{sleep\_mask} per riattivare \const{SIGALRM} all'esecuzione di
\func{sigsuspend}.
-In questo modo non sono più possibili race
-condition\index{\textit{race~condition}} dato che \const{SIGALRM} viene
+In questo modo non sono più possibili \textit{race
+ condition}\itindex{race~condition} dato che \const{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*}
\item Leggere la maschera dei segnali corrente e bloccare il segnale voluto
- con \func{sigprocmask}.
+ con \func{sigprocmask};
\item Mandare il processo in attesa con \func{sigsuspend} abilitando la
- ricezione del segnale voluto.
+ ricezione del segnale voluto;
\item Ripristinare la maschera dei segnali originaria.
\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\index{\textit{deadlock}} dovuto all'arrivo del segnale prima
-dell'esecuzione di \func{sigsuspend}.
-\index{\textit{signal mask}|)}
+deadlock\itindex{deadlock} dovuto all'arrivo del segnale prima dell'esecuzione
+di \func{sigsuspend}.
+
+\itindend{signal~mask}
\subsection{Ulteriori funzioni di gestione}
Scrive in \param{set} l'insieme dei segnali pendenti.
- \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
+ \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
errore.}
\end{prototype}
La funzione permette di ricavare quali sono i segnali pendenti per il processo
-in corso, cioè i segnali che sono stato inviati dal kernel ma non sono stati
+in corso, cioè i segnali che sono stati inviati dal kernel ma non sono stati
ancora ricevuti dal processo in quanto bloccati. Non esiste una funzione
equivalente nella vecchia interfaccia, ma essa è tutto sommato poco utile,
dato che essa può solo assicurare che un segnale è stato inviato, dato che
rispetto a quanto potrebbe essere in un qualunque momento successivo.
Una delle caratteristiche di BSD, disponibile anche in Linux, è la possibilità
-di usare uno stack alternativo per i segnali; è cioè possibile fare usare al
-sistema un altro stack (invece di quello relativo al processo, vedi
-sez.~\ref{sec:proc_mem_layout}) solo durante l'esecuzione di un
-gestore. L'uso di uno stack alternativo è del tutto trasparente ai
-gestori, occorre però seguire una certa procedura:
+di usare uno \itindex{stack} stack alternativo per i segnali; è cioè possibile
+fare usare al sistema un altro \itindex{stack} stack (invece di quello
+relativo al processo, vedi sez.~\ref{sec:proc_mem_layout}) solo durante
+l'esecuzione di un 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.
+ stack alternativo;
\item Usare la funzione \func{sigaltstack} per rendere noto al sistema
- l'esistenza e la locazione dello stack alternativo.
+ l'esistenza e la locazione dello stack alternativo;
\item Quando si installa un gestore occorre usare \func{sigaction}
specificando il flag \const{SA\_ONSTACK} (vedi tab.~\ref{tab:sig_sa_flag})
per dire al sistema di usare lo stack alternativo durante l'esecuzione del
memoria con \code{malloc}; in \file{signal.h} sono definite due costanti,
\const{SIGSTKSZ} e \const{MINSIGSTKSZ}, che possono essere utilizzate per
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.
+prima delle due è la dimensione canonica per uno \itindex{stack} 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 gestore e la dimensione di uno stack alternativo deve essere sempre
maggiore di questo valore. Quando si conosce esattamente quanto è lo spazio
necessario al gestore gli si può aggiungere questo valore per allocare uno
-stack di dimensione sufficiente.
+\itindex{stack} stack di dimensione sufficiente.
-Come accennato per poter essere usato lo stack per i segnali deve essere
-indicato al sistema attraverso la funzione \funcd{sigaltstack}; il suo
-prototipo è:
+Come accennato, per poter essere usato, lo \itindex{stack} stack per i segnali
+deve essere indicato al sistema attraverso la funzione \funcd{sigaltstack}; il
+suo prototipo è:
\begin{prototype}{signal.h}
{int sigaltstack(const stack\_t *ss, stack\_t *oss)}
Installa un nuovo stack per i segnali.
- \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
+ \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\end{prototype}
La funzione prende come argomenti puntatori ad una struttura di tipo
-\var{stack\_t}, definita in fig.~\ref{fig:sig_stack_t}. I due valori \param{ss}
-e \param{oss}, se non nulli, indicano rispettivamente il nuovo stack da
-installare e quello corrente (che viene restituito dalla funzione per un
-successivo ripristino).
+\var{stack\_t}, definita in fig.~\ref{fig:sig_stack_t}. I due valori
+\param{ss} e \param{oss}, se non nulli, indicano rispettivamente il nuovo
+\itindex{stack} stack da installare e quello corrente (che viene restituito
+dalla funzione per un successivo ripristino).
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:sig_stack_t}
\end{figure}
-Il campo \var{ss\_sp} di \struct{stack\_t} indica l'indirizzo base dello stack,
-mentre \var{ss\_size} ne indica la dimensione; il campo \var{ss\_flags} invece
-indica lo stato dello stack. Nell'indicare un nuovo stack occorre
-inizializzare \var{ss\_sp} e \var{ss\_size} rispettivamente al puntatore e
-alla dimensione della memoria allocata, mentre \var{ss\_flags} deve essere
-nullo. Se invece si vuole disabilitare uno stack occorre indicare
+Il campo \var{ss\_sp} di \struct{stack\_t} indica l'indirizzo base dello
+\itindex{stack} stack, mentre \var{ss\_size} ne indica la dimensione; il campo
+\var{ss\_flags} invece indica lo stato dello stack. Nell'indicare un nuovo
+stack occorre inizializzare \var{ss\_sp} e \var{ss\_size} rispettivamente al
+puntatore e alla dimensione della memoria allocata, mentre \var{ss\_flags}
+deve essere nullo. Se invece si vuole disabilitare uno stack occorre indicare
\const{SS\_DISABLE} come valore di \var{ss\_flags} e gli altri valori saranno
ignorati.
Se \param{oss} non è nullo verrà restituito dalla funzione indirizzo e
-dimensione dello stack corrente nei relativi campi, mentre \var{ss\_flags}
-potrà assumere il valore \const{SS\_ONSTACK} se il processo è in esecuzione
-sullo stack alternativo (nel qual caso non è possibile cambiarlo) e
-\const{SS\_DISABLE} se questo non è abilitato.
-
-In genere si installa uno stack alternativo per i segnali quando si teme di
-avere problemi di esaurimento dello stack standard o di superamento di un
-limite imposto con chiamata de tipo \code{setrlimit(RLIMIT\_STACK, \&rlim)}.
-In tal caso infatti si avrebbe un segnale di \const{SIGSEGV}, che potrebbe
-essere gestito soltanto avendo abilitato uno stack alternativo.
+dimensione dello \itindex{stack} stack corrente nei relativi campi, mentre
+\var{ss\_flags} potrà assumere il valore \const{SS\_ONSTACK} se il processo è
+in esecuzione sullo stack alternativo (nel qual caso non è possibile
+cambiarlo) e \const{SS\_DISABLE} se questo non è abilitato.
+
+In genere si installa uno \itindex{stack} stack alternativo per i segnali
+quando si teme di avere problemi di esaurimento dello stack standard o di
+superamento di un limite (vedi sez.~\ref{sec:sys_resource_limit}) imposto con
+chiamate del tipo \code{setrlimit(RLIMIT\_STACK, \&rlim)}. In tal caso
+infatti si avrebbe un segnale di \const{SIGSEGV}, che potrebbe essere gestito
+soltanto avendo abilitato uno \itindex{stack} stack alternativo.
Si tenga presente che le funzioni chiamate durante l'esecuzione sullo stack
alternativo continueranno ad usare quest'ultimo, che, al contrario di quanto
-avviene per lo stack ordinario dei processi, non si accresce automaticamente
-(ed infatti eccederne le dimensioni può portare a conseguenze imprevedibili).
-Si ricordi infine che una chiamata ad una funzione della famiglia
-\func{exec} cancella ogni stack alternativo.
+avviene per lo \itindex{stack} stack ordinario dei processi, non si accresce
+automaticamente (ed infatti eccederne le dimensioni può portare a conseguenze
+imprevedibili). Si ricordi infine che una chiamata ad una funzione della
+famiglia \func{exec} cancella ogni stack alternativo.
Abbiamo visto in fig.~\ref{fig:sig_sleep_incomplete} come si possa usare
\func{longjmp} per uscire da un gestore rientrando direttamente nel corpo
\end{functions}
Le due funzioni prendono come primo argomento la variabile su cui viene
-salvato il contesto dello stack per permettere il salto non-locale
-\index{salto~non-locale}; nel caso specifico essa è di tipo
+salvato il contesto dello \itindex{stack} stack per permettere il
+\index{salto~non-locale}salto non-locale; nel caso specifico essa è di tipo
\type{sigjmp\_buf}, e non \type{jmp\_buf} come per le analoghe di
sez.~\ref{sec:proc_longjmp} in quanto in questo caso viene salvata anche la
maschera dei segnali.
-Nel caso di \func{sigsetjmp} se si specifica un valore di \param{savesigs}
+Nel caso di \func{sigsetjmp}, se si specifica un valore di \param{savesigs}
diverso da zero la maschera dei valori sarà salvata in \param{env} e
ripristinata in un successivo \func{siglongjmp}; quest'ultima funzione, a
parte l'uso di \type{sigjmp\_buf} per \param{env}, è assolutamente identica a
\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.
+ accorgersi di quante volte l'evento che ha generato il segnale è accaduto;
\item[I segnali non trasportano informazione]
i segnali classici non 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).
+ 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
disponibile anche con i segnali ordinari) si applicano solo ai nuovi segnali
real-time; questi ultimi sono accessibili in un range di valori specificati
dalle due macro \const{SIGRTMIN} e \const{SIGRTMAX},\footnote{in Linux di
- solito il primo valore è 32, ed il secondo \code{\_NSIG-1}, che di norma è
- 63, per un totale di 32 segnali disponibili, contro gli almeno 8 richiesti
- da POSIX.1b.} che specificano il numero minimo e massimo associato ad un
-segnale real-time.
+ solito (cioè sulla piattaforma i386) il primo valore è 33, ed il secondo
+ \code{\_NSIG-1}, che di norma è 64, 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
forma estesa \var{sa\_sigaction} (vedi sez.~\ref{sec:sig_sigaction}). In
questo modo tutti i segnali real-time possono restituire al gestore una serie
di informazioni aggiuntive attraverso l'argomento \struct{siginfo\_t}, la cui
-definizione abbiamo già visto in fig.~\ref{fig:sig_siginfo_t}, nella
+definizione è stata già vista in fig.~\ref{fig:sig_siginfo_t}, nella
trattazione dei gestori in forma estesa.
In particolare i campi utilizzati dai segnali real-time sono \var{si\_pid} e
\end{figure}
A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
-inviare segnali real-time, poichè non è in grado di fornire alcun valore
+inviare segnali real-time, poiché non è in grado di fornire alcun valore
per \struct{sigval\_t}; per questo motivo lo standard ha previsto una nuova
funzione, \funcd{sigqueue}, il cui prototipo è:
\begin{prototype}{signal.h}
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
+ \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EAGAIN}] La coda è esaurita, ci sono già \const{SIGQUEUE\_MAX}
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
+stessi; un valore nullo di \param{signo} permette di verificare le condizioni
di errore senza inviare nessun segnale.
Se il segnale è bloccato la funzione ritorna immediatamente, se si è
(vale a dire che c'è posto\footnote{la profondità della coda è indicata dalla
costante \const{SIGQUEUE\_MAX}, una della tante costanti di sistema definite
dallo standard POSIX che non abbiamo riportato esplicitamente in
- sez.~\ref{sec:sys_limits}. Il suo valore minimo secondo lo standard,
+ sez.~\ref{sec:sys_limits}; il suo valore minimo secondo lo standard,
\const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux questo è uno
dei parametri del kernel impostabili sia con \func{sysctl}, che scrivendolo
direttamente in \file{/proc/sys/kernel/rtsig-max}, il valore predefinito è
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
+ \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINTR}] La funzione è stata interrotta.
timeout in \param{timeout}.
- \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
+ \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}
projects / gapil.git / blobdiff