%% signal.tex
%%
-%% Copyright (C) 2000-2003 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2004 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
-%% Free Software Foundation; with the Invariant Sections being "Prefazione",
+%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
%% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
%% license is included in the section entitled "GNU Free Documentation
%% License".
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
+fig.~\ref{fig:sig_old_handler}, nel programma principale viene installato un
gestore (\texttt{\small 5}), ed in quest'ultimo la prima operazione
(\texttt{\small 11}) è quella di reinstallare se stesso. Se nell'esecuzione
del gestore un secondo segnale arriva prima che esso abbia potuto eseguire la
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{race condition}
-(sull'argomento vedi quanto detto in \secref{sec:proc_multi_prog}).
+(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
segnali quando non si vuole che arrivino; i processi possono ignorare il
\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
-\figref{fig:proc_task_struct}).
+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
Si tenga presente che il kernel stabilisce cosa fare con un segnale che è
stato bloccato al momento della consegna, non quando viene generato; questo
consente di cambiare l'azione per il segnale prima che esso venga consegnato,
-e si può usare la funzione \func{sigpending} (vedi \secref{sec:sig_sigmask})
+e si può usare la funzione \func{sigpending} (vedi sez.~\ref{sec:sig_sigmask})
per determinare quali segnali sono bloccati e quali sono pendenti.
\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 gestore sarà
+\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{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
+standard che (come vedremo in sez.~\ref{sec:sig_standard}) è propria di ciascun
segnale; nella maggior parte dei casi essa porta alla terminazione del
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
-\func{wait} e \func{waitpid} (vedi \secref{sec:proc_wait}); questo è il modo
+\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.
Il numero totale di segnali presenti è dato dalla macro \const{NSIG}, e dato
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
+In tab.~\ref{tab:sig_signal_list} si è riportato l'elenco completo dei segnali
definiti in Linux (estratto dalle pagine di manuale), comparati con quelli
definiti in vari standard.
\hline
\end{tabular}
\caption{Legenda delle azioni predefinite dei segnali riportate in
- \tabref{tab:sig_signal_list}.}
+ tab.~\ref{tab:sig_signal_list}.}
\label{tab:sig_action_leg}
\end{table}
-In \tabref{tab:sig_signal_list} si sono anche riportate le azioni predefinite
+In tab.~\ref{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 gestore è installato un
+tab.~\ref{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}.
+è definito, secondo lo schema di tab.~\ref{tab:sig_standard_leg}.
\begin{table}[htb]
\hline
\end{tabular}
\caption{Legenda dei valori della colonna \textbf{Standard} di
- \tabref{tab:sig_signal_list}.}
+ tab.~\ref{tab:sig_signal_list}.}
\label{tab:sig_standard_leg}
\end{table}
avuto successo.
\item[\const{SIGURG}] Questo segnale è inviato quando arrivano dei dati
urgenti o \textit{out-of-band} su di un socket\index{socket}; per maggiori
- dettagli al proposito si veda \secref{sec:TCP_urgent_data}.
+ dettagli al proposito si veda sez.~\ref{sec:TCP_urgent_data}.
\item[\const{SIGPOLL}] Questo segnale è equivalente a \const{SIGIO}, è
definito solo per compatibilità con i sistemi System V.
\end{basedescript}
\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
- segnale, la sua gestione è trattata in \secref{sec:proc_wait}.
+ segnale, la sua gestione è trattata in sez.~\ref{sec:proc_wait}.
\item[\const{SIGCLD}] Per Linux questo è solo un segnale identico al
precedente, il nome è obsoleto e andrebbe evitato.
\item[\const{SIGCONT}] Il nome sta per \textit{continue}. Il segnale viene
se viene fermato e riavviato, come per esempio riscrivere un prompt, o
inviare un avviso.
\item[\const{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é
+ stato di sleep, vedi sez.~\ref{sec:proc_sched}); il segnale non può essere né
intercettato, né ignorato, né bloccato.
\item[\const{SIGTSTP}] Il nome sta per \textit{interactive stop}. Il segnale
ferma il processo interattivamente, ed è generato dal carattere SUSP
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}.
+ processo. L'argomento è trattato in
+ sez.~\ref{sec:sess_job_control_overview}.
\item[\const{SIGTTOU}] Segnale analogo al precedente \const{SIGTTIN}, ma
generato quando si tenta di scrivere o modificare uno dei modi del
terminale. L'azione predefinita è di fermare il processo, l'argomento è
- trattato in \secref{sec:sess_job_control_overview}.
+ trattato in sez.~\ref{sec:sess_job_control_overview}.
\end{basedescript}
\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
- \secref{sec:ipc_pipes}). Se il processo in lettura non è partito o è
+ 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}.
situazione precedente.
\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 \secref{sec:sys_resource_limit}.
+ tempo di CPU disponibile, vedi sez.~\ref{sec:sys_resource_limit}.
\item[\const{SIGXFSZ}] Sta per \textit{File size limit exceeded}. Questo
segnale è generato quando un processo tenta di estendere un file oltre le
dimensioni specificate dal limite impostato per le dimensioni massime di un
- file, vedi \secref{sec:sys_resource_limit}.
+ file, vedi sez.~\ref{sec:sys_resource_limit}.
\end{basedescript}
terminazione di un processo figlio o di un gestore che gestisce più segnali);
la prima funzione, \funcd{strsignal}, è una estensione GNU, accessibile avendo
definito \macro{\_GNU\_SOURCE}, ed è analoga alla funzione \func{strerror} (si
-veda \secref{sec:sys_strerror}) per gli errori:
+veda sez.~\ref{sec:sys_strerror}) per gli errori:
\begin{prototype}{string.h}{char *strsignal(int signum)}
Ritorna il puntatore ad una stringa che contiene la descrizione del segnale
\param{signum}.
necessario copiarlo.
La seconda funzione, \funcd{psignal}, deriva da BSD ed è analoga alla funzione
-\func{perror} descritta sempre in \secref{sec:sys_strerror}; il suo prototipo
+\func{perror} descritta sempre in sez.~\ref{sec:sys_strerror}; il suo prototipo
è:
\begin{prototype}{signal.h}{void psignal(int sig, const char *s)}
Stampa sullo standard error un messaggio costituito dalla stringa \param{s},
\subsection{Il comportamento generale del sistema.}
\label{sec:sig_gen_beha}
-Abbiamo già trattato in \secref{sec:sig_intro} le modalità con cui il sistema
+Abbiamo già trattato in sez.~\ref{sec:sig_intro} le modalità con cui il sistema
gestisce l'interazione fra segnali e processi, ci resta da esaminare però il
comportamento delle system call; in particolare due di esse, \func{fork} ed
\func{exec}, dovranno essere prese esplicitamente in considerazione, data la
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 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
-segnali dovuti alle sue azioni.
+Come accennato in sez.~\ref{sec:proc_fork} quando viene creato un nuovo
+processo esso eredita dal padre sia le azioni che sono state impostate per i
+singoli segnali, che la maschera dei segnali bloccati (vedi
+sez.~\ref{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 segnali dovuti alle sue azioni.
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
+quanto detto in sez.~\ref{sec:proc_exec}) tutti i segnali per i quali è stato
installato un gestore vengono reimpostati a \const{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.
\item la scrittura sugli stessi file, nel caso in cui dati non possano essere
accettati immediatamente.
\item l'apertura di un file di dispositivo che richiede operazioni non
- immediate per una una risposta.
+ immediate per una risposta.
\item le operazioni eseguite con \func{ioctl} che non è detto possano essere
eseguite immediatamente.
\item le funzioni di intercomunicazione che si bloccano in attesa di risposte
Linux e le \acr{glibc} consentono di utilizzare entrambi gli approcci,
attraverso una opportuna opzione di \func{sigaction} (vedi
-\secref{sec:sig_sigaction}). È da chiarire comunque che nel caso di
+sez.~\ref{sec:sig_sigaction}). È da chiarire comunque che nel caso di
interruzione nel mezzo di un trasferimento parziale di dati, le system call
ritornano sempre indicando i byte trasferiti.
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,
- vedremo in \secref{sec:sig_sigaction} che questo è possibile usando la
+ vedremo in sez.~\ref{sec:sig_sigaction} che questo è possibile usando la
funzione \func{sigaction}.} che è:
\begin{prototype}{signal.h}
{sighandler\_t signal(int signum, sighandler\_t handler)}
segnale.
Il numero di segnale passato in \param{signum} può essere indicato
-direttamente con una delle costanti definite in \secref{sec:sig_standard}. Il
+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
e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo delle
\acr{glibc} dalla versione 2 anche Linux è passato a questo comportamento. Il
comportamento della versione originale della funzione, il cui uso è deprecato
-per i motivi visti in \secref{sec:sig_semantics}, può essere ottenuto
+per i motivi visti in sez.~\ref{sec:sig_semantics}, può essere ottenuto
chiamando \func{sysv\_signal}, una volta che si sia definita la macro
\macro{\_XOPEN\_SOURCE}. In generale, per evitare questi problemi, l'uso di
\func{signal} (ed ogni eventuale ridefinizine della stessa) è da evitare;
\subsection{Le funzioni \func{kill} e \func{raise}}
\label{sec:sig_kill_raise}
-Come accennato in \secref{sec:sig_types}, un segnale può essere generato
+Come accennato in sez.~\ref{sec:sig_types}, un segnale può essere generato
direttamente da un processo attraverso una opportuna system call. Le funzioni
che si usano di solito per inviare un segnale generico sono due, \func{raise} e
\func{kill}.
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
+sez.~\ref{sec:sig_classification}. In genere questa funzione viene usata per
riprodurre il comportamento predefinito di un segnale che sia stato
intercettato. In questo caso, una volta eseguite le operazioni volute, il
gestore dovrà prima reinstallare l'azione predefinita, per poi attivarla
in tal caso si otterrà un errore \errcode{EPERM} se non si hanno i permessi
necessari ed un errore \errcode{ESRCH} se il processo specificato non esiste.
Si tenga conto però che il sistema ricicla i \acr{pid} (come accennato in
-\secref{sec:proc_pid}) per cui l'esistenza di un processo non significa che
+sez.~\ref{sec:proc_pid}) per cui l'esistenza di un processo non significa che
esso sia realmente quello a cui si intendeva mandare il segnale.
Il valore dell'argomento \param{pid} specifica il processo (o i processi) di
destinazione a cui il segnale deve essere inviato e può assumere i valori
-riportati in \tabref{tab:sig_kill_values}.
+riportati in tab.~\ref{tab:sig_kill_values}.
Si noti pertanto che la funzione \code{raise(sig)} può essere definita in
termini di \func{kill}, ed è sostanzialmente equivalente ad una
errore, gli errori sono gli stessi di \func{kill}.}
\end{prototype}
\noindent e che permette di inviare un segnale a tutto un \textit{process
- group} (vedi \secref{sec:sess_proc_group}).
+ group} (vedi sez.~\ref{sec:sess_proc_group}).
\begin{table}[htb]
\footnotesize
destinazione. Fa eccezione il caso in cui il segnale inviato sia
\const{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
+(si ricordi quanto visto in sez.~\ref{sec:sig_termination}), non è possibile
inviare al processo 1 (cioè a \cmd{init}) segnali per i quali esso non abbia
un gestore installato.
predisporre le opportune misure per gestire il caso di necessità di più
interruzioni.
-In \secref{sec:sys_unix_time} abbiamo visto che ad ogni processo sono
+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
il \textit{system time}. Per poterli calcolare il kernel mantiene per ciascun
processo tre diversi timer:
\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
- \secref{sec:sys_unix_time} abbiamo chiamato \textit{CPU time}). La scadenza
+ sez.~\ref{sec:sys_unix_time} abbiamo chiamato \textit{CPU time}). La scadenza
di questo timer provoca l'emissione di \const{SIGPROF}.
\end{itemize}
Il valore di \param{which} permette di specificare quale dei tre timer
illustrati in precedenza usare; i possibili valori sono riportati in
-\tabref{tab:sig_setitimer_values}.
+tab.~\ref{tab:sig_setitimer_values}.
\begin{table}[htb]
\footnotesize
\centering
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 \struct{itimerval}, definita in \figref{fig:file_stat_struct}.
+struttura \struct{itimerval}, definita in fig.~\ref{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
definita direttamente nello standard POSIX.1, può a sua volta essere espressa
in termini di \func{setitimer}, come evidenziato dal manuale delle \acr{glibc}
\cite{glibc} che ne riporta la definizione mostrata in
-\figref{fig:sig_alarm_def}.
+fig.~\ref{fig:sig_alarm_def}.
\begin{figure}[!htb]
\footnotesize \centering
conto poi che in caso di sistema molto carico, si può avere il caso patologico
in cui un timer scade prima che il segnale di una precedente scadenza sia
stato consegnato; in questo caso, per il comportamento dei segnali descritto
-in \secref{sec:sig_sigchld}, un solo segnale sarà consegnato.
+in sez.~\ref{sec:sig_sigchld}, un solo segnale sarà consegnato.
Dato che sia \func{alarm} che \func{setitimer} non consentono di leggere il
L'ultima funzione che permette l'invio diretto di un segnale è \funcd{abort};
-che, come accennato in \secref{sec:proc_termination}, permette di abortire
+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 è:
\begin{prototype}{stdlib.h}{void abort(void)}
sono apposite funzioni che permettono di mettere un processo in stato di
attesa.\footnote{si tratta in sostanza di funzioni che permettono di portare
esplicitamente il processo in stato di \textit{sleep}, vedi
- \secref{sec:proc_sched}.}
+ sez.~\ref{sec:proc_sched}.}
Il metodo tradizionale per fare attendere ad un processo fino all'arrivo di un
segnale è quello di usare la funzione \funcd{pause}, il cui prototipo è:
In alcune implementazioni inoltre l'uso di \func{sleep} può avere conflitti
con quello di \const{SIGALRM}, dato che la funzione può essere realizzata con
l'uso di \func{pause} e \func{alarm} (in maniera analoga all'esempio che
-vedremo in \secref{sec:sig_example}). In tal caso mescolare chiamata di
+vedremo in sez.~\ref{sec:sig_example}). In tal caso mescolare chiamata di
\func{alarm} e \func{sleep} o modificare l'azione di \const{SIGALRM}, può
causare risultati indefiniti. Nel caso delle \acr{glibc} è stata usata una
implementazione completamente indipendente e questi problemi non ci sono.
utilizzando direttamente il timer del kernel.} e sia utilizzabile senza
interferenze con l'uso di \const{SIGALRM}. La funzione prende come parametri
delle strutture di tipo \struct{timespec}, la cui definizione è riportata in
-\figref{fig:sys_timeval_struct}, che permettono di specificare un tempo con
+fig.~\ref{fig:sys_timeval_struct}, che permettono di specificare un tempo con
una precisione (teorica) fino al nanosecondo.
La funzione risolve anche il problema di proseguire l'attesa dopo
Un semplice esempio per illustrare il funzionamento di un gestore di segnale è
quello della gestione di \const{SIGCHLD}. Abbiamo visto in
-\secref{sec:proc_termination} che una delle azioni eseguite dal kernel alla
+sez.~\ref{sec:proc_termination} che una delle azioni eseguite dal kernel alla
conclusione di un processo è quella di inviare questo segnale al
padre.\footnote{in realtà in SVr4 eredita la semantica di System V, in cui il
segnale si chiama \const{SIGCLD} e viene trattato in maniera speciale; in
\func{waitpid} per completare la procedura di terminazione in modo da evitare
la formazione di zombie\index{zombie}.
-In \figref{fig:sig_sigchld_handl} è mostrato il codice contenente una
+In fig.~\ref{fig:sig_sigchld_handl} è mostrato il codice contenente una
implementazione generica di una routine di gestione per \const{SIGCHLD}, (che
si trova nei sorgenti allegati nel file \file{SigHand.c}); se ripetiamo i test
-di \secref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione
+di sez.~\ref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione
\cmd{-s} (che si limita ad effettuare l'installazione di questa funzione come
gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione
di zombie\index{zombie}.
\end{figure}
Il codice del gestore è di lettura immediata; come buona norma di
-programmazione (si ricordi quanto accennato \secref{sec:sys_errno}) si
+programmazione (si ricordi quanto accennato sez.~\ref{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 gestore
(\texttt{\small 22-23}). In questo modo si preserva il valore della variabile
generazione di un segnale e l'esecuzione del gestore possa passare un certo
lasso di tempo e niente ci assicura che il gestore venga eseguito prima della
generazione di ulteriori segnali dello stesso tipo. In questo caso normalmente
-i segnali segnali successivi vengono ``\textsl{fusi}'' col primo ed al
-processo ne viene recapitato soltanto uno.
+i segnali successivi vengono ``\textsl{fusi}'' col primo ed al processo ne
+viene recapitato soltanto uno.
Questo può essere un caso comune proprio con \const{SIGCHLD}, qualora capiti
che molti processi figli terminino in rapida successione. Esso inoltre si
Per questo occorre ripetere la chiamata di \func{waitpid} fino a che essa non
ritorni un valore nullo, segno che non resta nessun processo di cui si debba
-ancora ricevere lo stato di terminazione (si veda \secref{sec:proc_wait} per
+ancora ricevere lo stato di terminazione (si veda sez.~\ref{sec:proc_wait} per
la sintassi della funzione). Si noti anche come la funzione venga invocata con
il parametro \const{WNOHANG} che permette di evitare il suo blocco quando
tutti gli stati di terminazione sono stati ricevuti.
\subsection{Alcune problematiche aperte}
\label{sec:sig_example}
-Come accennato in \secref{sec:sig_pause_sleep} è possibile implementare
+Come accennato in sez.~\ref{sec:sig_pause_sleep} è possibile implementare
\func{sleep} a partire dall'uso di \func{pause} e \func{alarm}. A prima vista
questo può sembrare di implementazione immediata; ad esempio una semplice
versione di \func{sleep} potrebbe essere quella illustrata in
-\figref{fig:sig_sleep_wrong}.
+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
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
+SVr2) usando la funzione \func{longjmp} (vedi sez.~\ref{sec:proc_longjmp}) per
uscire dal gestore; in questo modo, con una condizione sullo stato di
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}.
+codice del tipo di quello riportato in fig.~\ref{fig:sig_sleep_incomplete}.
\begin{figure}[!htb]
\footnotesize \centering
\end{figure}
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
+fig.~\ref{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
(\texttt{\small 9-12}) si evita comunque che \func{pause} sia chiamata a
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}).
+fig.~\ref{fig:sig_event_wrong}).
\begin{figure}[!htb]
\footnotesize\centering
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\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.
+Questo è il tipico esempio di caso, già citato in
+sez.~\ref{sec:proc_race_cond}, 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
In genere si usa un insieme di segnali per specificare quali segnali si vuole
bloccare, o per riottenere dalle varie funzioni di gestione la maschera dei
-segnali attivi (vedi \secref{sec:sig_sigmask}). Essi possono essere definiti
+segnali attivi (vedi sez.~\ref{sec:sig_sigmask}). Essi possono essere definiti
in due diverse maniere, aggiungendo i segnali voluti ad un insieme vuoto
ottenuto con \func{sigemptyset} o togliendo quelli che non servono da un
insieme completo ottenuto con \func{sigfillset}. Infine \func{sigismember}
\subsection{La funzione \func{sigaction}}
\label{sec:sig_sigaction}
-Abbiamo già accennato in \secref{sec:sig_signal} i problemi di compatibilità
+Abbiamo già accennato in sez.~\ref{sec:sig_signal} i problemi di compatibilità
relativi all'uso di \func{signal}. Per ovviare a tutto questo lo standard
POSIX.1 ha ridefinito completamente l'interfaccia per la gestione dei segnali,
rendendola molto più flessibile e robusta, anche se leggermente più complessa.
Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
tramite la quale si specificano tutte le caratteristiche dell'azione associata
ad un segnale. Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
-definita secondo quanto riportato in \figref{fig:sig_sigaction}. Il campo
+definita secondo quanto riportato in fig.~\ref{fig:sig_sigaction}. Il campo
\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
più usato.
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
gestore ritorna comunque la maschera dei segnali bloccati (vedi
-\secref{sec:sig_sigmask}) viene ripristinata al valore precedente
+sez.~\ref{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
+fig.~\ref{fig:sig_sleep_incomplete}. In quel caso infatti se il segnale di
allarme avesse interrotto un altro gestore questo non sarebbe stato
eseguito correttamente; la cosa poteva essere prevenuta installando gli altri
gestori usando \var{sa\_mask} per bloccare \const{SIGALRM} durante la
loro esecuzione. Il valore di \var{sa\_flag} permette di specificare vari
aspetti del comportamento di \func{sigaction}, e della reazione del processo
ai vari segnali; i valori possibili ed il relativo significato sono riportati
-in \tabref{tab:sig_sa_flag}.
+in tab.~\ref{tab:sig_sa_flag}.
\begin{table}[htb]
\footnotesize
\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
- \secref{sec:sig_specific_features}).\\
+ sez.~\ref{sec:sig_specific_features}).\\
\hline
\end{tabular}
\caption{Valori del campo \var{sa\_flag} della struttura \struct{sigaction}.}
\label{tab:sig_sa_flag}
\end{table}
-Come si può notare in \figref{fig:sig_sigaction} \func{sigaction}
+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 \secref{sec:sig_real_time}). In precedenza era possibile
+ 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
è quella classica usata anche con \func{signal}, mentre la prima permette di
usare un gestore più complesso, in grado di ricevere informazioni più
dettagliate dal sistema, attraverso la struttura \struct{siginfo\_t},
-riportata in \figref{fig:sig_siginfo_t}.
+riportata in fig.~\ref{fig:sig_siginfo_t}.
\begin{figure}[!htb]
\footnotesize \centering
altre informazioni specifiche. In tutti i casi il valore del campo è
riportato attraverso delle costanti (le cui definizioni si trovano
\file{bits/siginfo.h}) il cui elenco dettagliato è disponibile nella pagina di
-manuale di di \func{sigaction}.
+manuale di \func{sigaction}.
Il resto della struttura è definito come \ctyp{union} ed i valori
eventualmente presenti dipendono dal segnale, così \const{SIGCHLD} ed i
-segnali real-time (vedi \secref{sec:sig_real_time}) inviati tramite
+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 \secref{sec:file_asyncronous_io})
+è 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}.
Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
che abbia le stesse caratteristiche di \func{signal}, a definire attraverso
\func{sigaction} una funzione equivalente, il cui codice è riportato in
-\figref{fig:sig_Signal_code} (il codice completo si trova nel file
+fig.~\ref{fig:sig_Signal_code} (il codice completo si trova nel file
\file{SigHand.c} nei sorgenti allegati). Si noti come, essendo la funzione
estremamente semplice, è definita come \direct{inline}.\footnote{la direttiva
\direct{inline} viene usata per dire al compilatore di trattare la funzione
\textit{signal mask}}
\label{sec:sig_sigmask}
-Come spiegato in \secref{sec:sig_semantics} tutti i moderni sistemi unix-like
+Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like
permettono si bloccare temporaneamente (o di eliminare completamente,
impostando \const{SIG\_IGN} come azione) la consegna dei segnali ad un
processo. Questo è fatto specificando la cosiddetta \textsl{maschera dei
segnali} (o \textit{signal mask}) del processo\footnote{nel caso di Linux
essa è mantenuta dal campo \var{blocked} della \struct{task\_struct} del
processo.} cioè l'insieme dei segnali la cui consegna è bloccata. Abbiamo
-accennato in \secref{sec:proc_fork} che la \textit{signal mask} viene
+accennato in sez.~\ref{sec:proc_fork} che la \textit{signal mask} viene
ereditata dal padre alla creazione di un processo figlio, e abbiamo visto al
paragrafo precedente che essa può essere modificata, durante l'esecuzione di
un gestore, attraverso l'uso dal campo \var{sa\_mask} di \struct{sigaction}.
-Uno dei problemi evidenziatisi con l'esempio di \secref{fig:sig_event_wrong} è
-che in molti casi è necessario proteggere delle sezioni di codice (nel caso in
-questione la sezione fra il controllo e la eventuale cancellazione del flag
+Uno dei problemi evidenziatisi con l'esempio di fig.~\ref{fig:sig_event_wrong}
+è che in molti casi è necessario proteggere delle sezioni di codice (nel caso
+in questione la sezione fra il controllo e la eventuale cancellazione del flag
che testimoniava l'avvenuta occorrenza del segnale) in modo da essere sicuri
che essi siano eseguiti senza interruzioni.
La funzione usa l'insieme di segnali dato all'indirizzo \param{set} per
modificare la maschera dei segnali del processo corrente. La modifica viene
effettuata a seconda del valore dell'argomento \param{how}, secondo le modalità
-specificate in \tabref{tab:sig_procmask_how}. Qualora si specifichi un valore
+specificate in tab.~\ref{tab:sig_procmask_how}. Qualora si specifichi un valore
non nullo per \param{oldset} la maschera dei segnali corrente viene salvata a
quell'indirizzo.
In questo modo diventa possibile proteggere delle sezioni di codice bloccando
l'insieme di segnali voluto per poi riabilitarli alla fine della sezione
critica. La funzione permette di risolvere problemi come quelli mostrati in
-\secref{fig:sig_event_wrong}, proteggendo la sezione fra il controllo del flag
-e la sua cancellazione.
+fig.~\ref{fig:sig_event_wrong}, proteggendo la sezione fra il controllo del
+flag e la sua cancellazione.
La funzione può essere usata anche all'interno di un gestore, ad esempio
per riabilitare la consegna del segnale che l'ha invocato, in questo caso però
Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
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è
+problema illustrato nell'esempio di fig.~\ref{fig:sig_sleep_incomplete}, e cioè
la possibilità che il processo riceva il segnale che si intende usare per
uscire dallo stato di attesa invocato con \func{pause} immediatamente prima
dell'esecuzione di quest'ultima. Per poter effettuare atomicamente la modifica
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
-\const{SIGALRM} nell'installazione dei gestori degli altri segnali, per
-poter usare l'implementazione vista in \secref{fig:sig_sleep_incomplete} senza
+sez.~\ref{sec:sig_sigaction} come con \func{sigaction} sia possibile bloccare
+\const{SIGALRM} nell'installazione dei gestori degli altri segnali, per poter
+usare l'implementazione vista in fig.~\ref{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
-ottenere un'implementazione, riportata in \figref{fig:sig_sleep_ok} che non
+ottenere un'implementazione, riportata in fig.~\ref{fig:sig_sleep_ok} che non
presenta neanche questa necessità.
\begin{figure}[!htb]
\end{figure}
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 gestore (\texttt{\small 35-37})
+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})
non esegue nessuna operazione, limitandosi a ritornare per interrompere il
programma messo in attesa.
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
-\secref{sec:proc_mem_layout}) solo durante l'esecuzione di un
+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 Usare la funzione \func{sigaltstack} per rendere noto al sistema
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 \tabref{tab:sig_sa_flag}) per
- dire al sistema di usare lo stack alternativo durante l'esecuzione del
- gestore.
+ 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
+ gestore.
\end{enumerate}
In genere il primo passo viene effettuato allocando un'opportuna area di
\end{prototype}
La funzione prende come argomenti puntatori ad una struttura di tipo
-\var{stack\_t}, definita in \figref{fig:sig_stack_t}. I due valori \param{ss}
+\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).
Si ricordi infine che una chiamata ad una funzione della famiglia
\func{exec} cancella ogni stack alternativo.
-Abbiamo visto in \secref{fig:sig_sleep_incomplete} come si possa usare
+Abbiamo visto in fig.~\ref{fig:sig_sleep_incomplete} come si possa usare
\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
Lo standard POSIX.1 non specifica questo comportamento per \func{setjmp} e
\func{longjmp}, ed il comportamento delle \acr{glibc} dipende da quale delle
caratteristiche si sono abilitate con le macro viste in
-\secref{sec:intro_gcc_glibc_std}.
+sez.~\ref{sec:intro_gcc_glibc_std}.
Lo standard POSIX però prevede anche la presenza di altre due funzioni
\funcd{sigsetjmp} e \funcd{siglongjmp}, che permettono di decidere quale dei
non-locale su un precedente contesto.
\bodydesc{Le due funzioni sono identiche alle analoghe \func{setjmp} e
- \func{longjmp} di \secref{sec:proc_longjmp}, ma consentono di specificare
+ \func{longjmp} di sez.~\ref{sec:proc_longjmp}, ma consentono di specificare
il comportamento sul ripristino o meno della maschera dei segnali.}
\end{functions}
salvato il contesto dello stack per permettere il salto non-locale
\index{salto non-locale}; nel caso specifico essa è di tipo
\type{sigjmp\_buf}, e non \type{jmp\_buf} come per le analoghe di
-\secref{sec:proc_longjmp} in quanto in questo caso viene salvata anche la
+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}
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
+ 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).
\item[I segnali non hanno un ordine di consegna]
Si tenga presente che questi nuovi segnali non sono associati a nessun evento
specifico, a meno di non utilizzarli in meccanismi di notifica come quelli per
-l'I/O asincrono (vedi \secref{sec:file_asyncronous_io}) o per le code di
-messaggi POSIX (vedi \secref{sec:ipc_posix_mq}); pertanto devono essere
+l'I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io}) o per le code di
+messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}); pertanto devono essere
inviati esplicitamente.
Inoltre, per poter usufruire della capacità di restituire dei dati, i relativi
gestori devono essere installati con \func{sigaction}, specificando per
\var{sa\_flags} la modalità \const{SA\_SIGINFO} che permette di utilizzare la
-forma estesa \var{sa\_sigaction} (vedi \secref{sec:sig_sigaction}). In questo
-modo tutti i segnali real-time possono restituire al gestore una serie di
-informazioni aggiuntive attraverso l'argomento \struct{siginfo\_t}, la cui
-definizione abbiamo già visto in \figref{fig:sig_siginfo_t}, nella trattazione
-dei gestori in forma estesa.
+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
+trattazione dei gestori in forma estesa.
In particolare i campi utilizzati dai segnali real-time sono \var{si\_pid} e
\var{si\_uid} in cui vengono memorizzati rispettivamente il \acr{pid} e
restituzione dei dati viene usato il campo \var{si\_value}.
Questo è una \ctyp{union} di tipo \struct{sigval\_t} (la sua definizione è in
-\figref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico,
+fig.~\ref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico,
se usata nella forma \var{sival\_int}, o un indirizzo, se usata nella forma
\var{sival\_ptr}. L'unione viene usata dai segnali real-time e da vari
meccanismi di notifica\footnote{un campo di tipo \struct{sigval\_t} è presente
anche nella struttura \struct{sigevent} che viene usata dai meccanismi di
notifica come quelli per l'I/O asincrono (vedi
- \secref{sec:file_asyncronous_io}) o le code di messaggi POSIX (vedi
- \secref{sec:ipc_posix_mq}).} per restituire dati al gestore del segnale; in
+ sez.~\ref{sec:file_asyncronous_io}) o le code di messaggi POSIX (vedi
+ sez.~\ref{sec:ipc_posix_mq}).} per restituire dati al gestore del segnale; in
alcune definizioni essa viene identificata anche come \code{union sigval}.
\begin{figure}[!htb]
(vale a dire che c'è posto\footnote{la profondità della coda è indicata dalla
costante \const{SIGQUEUE\_MAX}, una della tante costanti di sistema definite
dallo standard POSIX che non abbiamo riportato esplicitamente in
- \secref{sec:sys_limits}. Il suo valore minimo secondo lo standard,
+ 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 è
projects / gapil.git / blobdiff