%% signal.tex
%%
-%% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2005 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".
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}).
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).
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
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
- \begin{lstlisting}{}
-int sig_handler(); /* handler function */
-int main()
-{
- ...
- signal(SIGINT, sig_handler); /* establish handler */
- ...
-}
-
-int sig_handler()
-{
- signal(SIGINT, sig_handler); /* restablish handler */
- ... /* process signal */
-}
- \end{lstlisting}
+ \includecodesample{listati/unreliable_sig.c}
\end{minipage}
\normalsize
\caption{Esempio di codice di un gestore di segnale per la semantica
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{race condition}
-(sull'argomento vedi quanto detto in \secref{sec:proc_multi_prog}).
+segnale e la reinstallazione del suo gestore non sono operazioni atomiche, e
+sono sempre possibili delle race condition\index{\textit{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.
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 \var{task\_struct} del processo nella process table (si veda
-\figref{fig:proc_task_struct}).
+campo della \struct{task\_struct} del processo nella 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{scheduler} quando,
+procedura viene effettuata dallo scheduler\index{\textit{scheduler}} quando,
riprendendo l'esecuzione del processo in questione, verifica la presenza del
-segnale nella \var{task\_struct} e mette in esecuzione il gestore.
+segnale nella \struct{task\_struct} e mette in esecuzione il gestore.
In questa semantica un processo ha la possibilità di bloccare la consegna dei
segnali, in questo caso, se l'azione per il suddetto segnale non è quella di
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.
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
Come accennato quando un segnale viene generato, se la sua azione predefinita
non è quella di essere ignorato, il kernel prende nota del fatto nella
-\var{task\_struct} del processo; si dice così che il segnale diventa
+\struct{task\_struct} del processo; si dice così che il segnale diventa
\textsl{pendente} (o \textit{pending}), e rimane tale fino al momento in cui
verrà notificato al processo (o verrà specificata come azione quella di
ignorarlo).
Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
avviene non appena questo viene rimesso in esecuzione dallo
-scheduler\index{scheduler} che esegue l'azione specificata. Questo a meno che
-il segnale in questione non sia stato bloccato prima della notifica, nel qual
-caso l'invio non avviene ed il segnale resta \textsl{pendente}
+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}
indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
-notificato.
+notificato. Si tenga presente però che i segnali \textsl{pendenti} non si
+accodano, alla generazione infatti il kernel marca un flag nella
+\struct{task\_struct} del processo, per cui se prima della notifica ne vengono
+generati altri il flag è comunque marcato, ed il gestore viene eseguito sempre
+una sola volta.
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é ciò che viene
-bloccata è la notifica). Per questo motivo un segnale, fintanto che viene
-ignorato, non sarà mai notificato, anche se è stato bloccato ed in seguito si
-è specificata una azione diversa (nel qual caso solo i segnali successivi alla
-nuova specificazione saranno notificati).
+e questo anche se in quel momento il segnale è bloccato (perché bloccare su un
+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 volta che un segnale viene notificato (che questo avvenga subito o dopo
una attesa più o meno lunga) viene eseguita l'azione specificata per il
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 \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}).
+condition\index{\textit{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
+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.
\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}.
+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
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}
\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}
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:
+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
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
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.
\item[\const{SIGTERM}] Il nome sta per \textit{terminate}. È un segnale
generico usato per causare la conclusione di un programma. Al contrario di
\const{SIGKILL} può essere intercettato, ignorato, bloccato. In genere lo si
- usa per chiedere in maniera ``educata'' ad un processo di concludersi.
+ usa per chiedere in maniera ``\textsl{educata}'' ad un processo di
+ concludersi.
\item[\const{SIGINT}] Il nome sta per \textit{interrupt}. È il segnale di
interruzione per il programma. È quello che viene generato di default dal
comando \cmd{kill} o dall'invio sul terminale del carattere di controllo
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.
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
questo può essere usato anche per i file, posto che la \func{fcntl} abbia
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:xxx_urgent_data}.
+ urgenti o \textit{out-of-band} su di un socket\index{socket}; per maggiori
+ 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}
\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
- 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}
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 è necessario che, prima che un processo inizi a scrivere su di
- essa, un'altro abbia aperto la pipe in lettura (si veda
- \secref{sec:ipc_pipes}). Se il processo in lettura non è partito o è
+\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
+ 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.
+ lo ha causato fallisce, restituendo l'errore \errcode{EPIPE}.
+\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 \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}
\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}] Vedi \const{SIGUSR2}.
-\item[\const{SIGUSR2}] Insieme a \const{SIGUSR1} è un segnale a disposizione
- dell'utente che li può usare per quello che vuole. Possono essere utili per
- implementare una comunicazione elementare fra processi diversi, o per
- eseguire a richiesta una operazione utilizzando un gestore. L'azione
- predefinita è di terminare il processo.
+\item[\const{SIGUSR1}] Insieme a \const{SIGUSR2} è un segnale a disposizione
+ dell'utente che lo può usare per quello che vuole. Viene generato solo
+ attraverso l'invocazione della funzione \func{kill}. Entrambi i segnali
+ possono essere utili per implementare una comunicazione elementare fra
+ processi diversi, o per eseguire a richiesta una operazione utilizzando un
+ gestore. L'azione predefinita è di terminare il processo.
+\item[\const{SIGUSR2}] È il secondo segnale a dispozione degli utenti. Vedi
+ quanto appena detto per \const{SIGUSR1}.
\item[\const{SIGWINCH}] Il nome sta per \textit{window (size) change} e viene
generato in molti sistemi (GNU/Linux compreso) quando le dimensioni (in
righe e colonne) di un terminale vengono cambiate. Viene usato da alcuni
\subsection{Le funzioni \func{strsignal} e \func{psignal}}
\label{sec:sig_strsignal}
-Per la descrizione dei segnali il sistema mette a disposizione due funzioni,
-\func{strsignal} e \func{psignal}, che stampano un messaggio di descrizione
-dato il numero. In genere si usano quando si vuole notificare all'utente il
-segnale avvenuto (nel caso di terminazione di un processo figlio o di un
-gestore che gestisce più segnali); la prima funzione è una estensione
-GNU, accessibile avendo definito \macro{\_GNU\_SOURCE}, ed è analoga alla
-funzione \func{strerror} (si veda \secref{sec:sys_strerror}) per gli errori:
+Per la descrizione dei segnali il sistema mette a disposizione due funzioni
+che stampano un messaggio di descrizione dato il numero. In genere si usano
+quando si vuole notificare all'utente il segnale ricevuto (nel caso di
+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 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
- \var{signum}.
+ \param{signum}.
\end{prototype}
\noindent dato che la stringa è allocata staticamente non se ne deve
modificare il contenuto, che resta valido solo fino alla successiva chiamata
di \func{strsignal}. Nel caso si debba mantenere traccia del messaggio sarà
necessario copiarlo.
-La seconda funzione deriva da BSD ed è analoga alla funzione \func{perror}
-descritta sempre in \secref{sec:sys_strerror}; il suo prototipo è:
+La seconda funzione, \funcd{psignal}, deriva da BSD ed è analoga alla funzione
+\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},
seguita da due punti ed una descrizione del segnale indicato da \param{sig}.
\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:
-\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
- extern const char *const sys_siglist[]
-\end{lstlisting}
-l'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
+\includecodesnip{listati/siglist.c}
+
+L'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
indicizzate per numero di segnale, per cui una chiamata del tipo di \code{char
*decr = strsignal(SIGINT)} può essere sostituita dall'equivalente \code{char
*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 \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.
successiva pressione di \texttt{C-c} o \texttt{C-y}.
Per quanto riguarda il comportamento di tutte le altre system call si danno
-sostanzialmente due casi, a seconda che esse siano \textsl{lente}
-(\textit{slow}) o \textsl{veloci} (\textit{fast}). La gran parte di esse
-appartiene a quest'ultima categoria, che non è influenzata dall'arrivo di un
-segnale. Esse sono dette \textsl{veloci} in quanto la loro esecuzione è
-sostanzialmente immediata; la risposta al segnale viene sempre data dopo che
-la system call è stata completata, in quanto attendere per eseguire un
-gestore non comporta nessun inconveniente.
+sostanzialmente due casi, a seconda che esse siano\index{system~call~lente}
+\textsl{lente} (\textit{slow}) o \textsl{veloci} (\textit{fast}). La gran
+parte di esse appartiene a quest'ultima categoria, che non è influenzata
+dall'arrivo di un segnale. Esse sono dette \textsl{veloci} in quanto la loro
+esecuzione è sostanzialmente immediata; la risposta al segnale viene sempre
+data dopo che la system call è stata completata, in quanto attendere per
+eseguire un gestore non comporta nessun inconveniente.
In alcuni casi però alcune system call (che per questo motivo vengono chiamate
\textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può
-attendere la conclusione della sistem call, perché questo renderebbe
+attendere la conclusione della system call, perché questo renderebbe
impossibile una risposta pronta al segnale, per cui il gestore viene
eseguito prima che la system call sia ritornata. Un elenco dei casi in cui si
presenta questa situazione è il seguente:
-\begin{itemize}
+\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).
+ presenti (come per certi file di dispositivo\index{file!di~dispositivo}, i
+ 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 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}
+\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
non è diverso dall'uscita con un errore \errcode{EINTR}.
La soluzione è comunque poco elegante e BSD ha scelto un approccio molto
-diverso, che è quello di fare ripartire automaticamente la system call invece
-di farla fallire. In questo caso ovviamente non c'è da preoccuparsi di
-controllare il codice di errore; si perde però la possibilità di eseguire
-azioni specifiche all'occorrenza di questa particolare condizione.
+diverso, che è quello di fare ripartire automaticamente una system call
+interrotta invece di farla fallire. In questo caso ovviamente non c'è bisogno
+di preoccuparsi di controllare il codice di errore; si perde però la
+possibilità di eseguire azioni specifiche all'occorrenza di questa particolare
+condizione.
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.
\label{sec:sig_signal}
L'interfaccia più semplice per la gestione dei segnali è costituita dalla
-funzione \func{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,
- vedremo in \secref{sec:sig_sigaction} che questo è possibile usando la
+ 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}
{sighandler\_t signal(int signum, sighandler\_t handler)}
\end{prototype}
In questa definizione si è usato un tipo di dato, \type{sighandler\_t}, che è
-una estensione GNU, definita dalle \acr{glibc}, esso permette di riscrivere il
-prototipo di \func{signal} nella forma appena vista, che risulta molto più
-leggibile di quanto non sia la versione originaria che di norma è definita
-come:
-\begin{verbatim}
- void (*signal(int signum, void (*handler)(int)))int)
-\end{verbatim}
+una estensione GNU, definita dalle \acr{glibc}, che permette di riscrivere il
+prototipo di \func{signal} nella forma appena vista, molto più leggibile di
+quanto non sia la versione originaria, che di norma è definita come:
+\includecodesnip{listati/signal.c}
questa infatti, per la poca chiarezza della sintassi del C quando si vanno a
trattare puntatori a funzioni, è molto meno comprensibile. Da un confronto
con il precedente prototipo si può dedurre la definizione di
\type{sighandler\_t} che è:
-\begin{verbatim}
- typedef void (* sighandler_t)(int)
-\end{verbatim}
+\includecodesnip{listati/sighandler_t.c}
e cioè un puntatore ad una funzione \ctyp{void} (cioè senza valore di ritorno)
e che prende un argomento di tipo \ctyp{int}.\footnote{si devono usare le
parentesi intorno al nome della funzione per via delle precedenze degli
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
+\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é
- intercettati.}
+ \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.}
La funzione restituisce l'indirizzo dell'azione precedente, che può essere
salvato per poterlo ripristinare (con un'altra chiamata a \func{signal}) in un
L'uso di \func{signal} è soggetto a problemi di compatibilità, dato che essa
si comporta in maniera diversa per sistemi derivati da BSD o da System V. In
questi ultimi infatti la funzione è conforme al comportamento originale dei
-primi Unix in cui il gestore viene disinstallato alla sua chiamata,
-secondo la semantica inaffidabile; Linux seguiva questa convenzione fino alle
-\acr{libc5}. Al contrario BSD segue la semantica affidabile, non
-disinstallando il gestore e bloccando il segnale durante l'esecuzione
-dello stesso. Con l'utilizzo delle \acr{glibc} dalla versione 2 anche Linux è
-passato a questo comportamento; quello della versione originale della
-funzione, il cui uso è deprecato per i motivi visti in
-\secref{sec:sig_semantics}, può essere ottenuto chiamando \func{sysv\_signal}.
-In generale, per evitare questi problemi, tutti i nuovi programmi dovrebbero
-usare \func{sigaction}.
+primi Unix in cui il gestore viene disinstallato alla sua chiamata, secondo la
+semantica inaffidabile; anche Linux seguiva questa convenzione con le vecchie
+librerie del C come le \acr{libc4} e le \acr{libc5}.\footnote{nelle
+ \acr{libc5} esiste però la possibilità di includere \file{bsd/signal.h} al
+ posto di \file{signal.h}, nel qual caso la funzione \func{signal} viene
+ ridefinita per seguire la semantica affidabile usata da BSD.}
+
+Al contrario BSD segue la semantica affidabile, non disinstallando il gestore
+e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo delle
+\acr{glibc} dalla versione 2 anche Linux è passato a questo comportamento. Il
+comportamento della versione originale della funzione, il cui uso è deprecato
+per i motivi visti in 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;
+tutti i nuovi programmi dovrebbero usare \func{sigaction}.
È da tenere presente che, seguendo lo standard POSIX, il comportamento di un
processo che ignora i segnali \const{SIGFPE}, \const{SIGILL}, o
-\const{SIGSEGV} (qualora non originino da una \func{kill} o una \func{raise})
-è indefinito. Un gestore che ritorna da questi segnali può dare luogo ad
-un ciclo infinito.
+\const{SIGSEGV} (qualora questi non originino da una chiamata ad una
+\func{kill} o ad una \func{raise}) è indefinito. Un gestore che ritorna da
+questi segnali può dare luogo ad un ciclo infinito.
\subsection{Le funzioni \func{kill} e \func{raise}}
\label{sec:sig_kill_raise}
-Come accennato in \secref{sec:sig_types}, un segnale può essere generato
-direttamente da un processo. L'invio di un segnale generico può essere
-effettuato attraverso delle funzioni \func{kill} e \func{raise}. La prima
-serve per inviare un segnale al processo corrente, ed il suo prototipo è:
+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}.
+
+La prima funzione è \funcd{raise}, che è definita dallo standard ANSI C, e
+serve per inviare un segnale al processo corrente,\footnote{non prevedendo la
+ presenza di un sistema multiutente lo standard ANSI C non poteva che
+ definire una funzione che invia il segnale al programma in esecuzione. Nel
+ caso di Linux questa viene implementata come funzione di compatibilità.} il
+suo prototipo è:
\begin{prototype}{signal.h}{int raise(int sig)}
Invia il segnale \param{sig} al processo corrente.
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 potrà reinstallare l'azione predefinita, e attivarla con \func{raise}.
+gestore dovrà prima reinstallare l'azione predefinita, per poi attivarla
+chiamando \func{raise}.
-Se invece si vuole inviare un segnale ad un altro processo occorre utilizzare
-la funzione \func{kill}; il cui prototipo è:
+Mentre \func{raise} è una funzione di libreria, quando si vuole inviare un
+segnale generico ad un processo occorre utilizzare la apposita system call,
+questa può essere chiamata attraverso la funzione \funcd{kill}, il cui
+prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{signal.h}
\end{functions}
Lo standard POSIX prevede che il valore 0 per \param{sig} sia usato per
-specificare il segnale nullo. Se le funzioni vengono chiamate con questo
-valore non viene inviato nessun segnale, ma viene eseguito il controllo degli
-errori, 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
+specificare il segnale nullo. Se la funzione viene chiamata con questo valore
+non viene inviato nessun segnale, ma viene eseguito il controllo degli errori,
+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
+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
+\code{kill(getpid(), sig)}. Siccome \func{raise}, che è definita nello
+standard ISO C, non esiste in alcune vecchie versioni di Unix, in generale
+l'uso di \func{kill} finisce per essere più portabile.
+
+Una seconda funzione che può essere definita in termini di \func{kill} è
+\funcd{killpg}, che è sostanzialmente equivalente a
+\code{kill(-pidgrp, signal)}; il suo prototipo è:
+\begin{prototype}{signal.h}{int killpg(pid\_t pidgrp, int signal)}
+
+ Invia il segnale \param{signal} al process group \param{pidgrp}.
+ \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ errore, gli errori sono gli stessi di \func{kill}.}
+\end{prototype}
+\noindent e permette di inviare un segnale a tutto un \textit{process group}
+(vedi sez.~\ref{sec:sess_proc_group}).
+
\begin{table}[htb]
\footnotesize
\centering
\label{tab:sig_kill_values}
\end{table}
-Si noti pertanto che la funzione \code{raise(sig)} può essere definita in
-termini di \func{kill}, ed è sostanzialmente equivalente ad una
-\code{kill(getpid(), sig)}. Siccome \func{raise}, che è definita nello
-standard ISO C, non esiste in alcune vecchie versioni di Unix, in generale
-l'uso di \func{kill} finisce per essere più portabile.
-
-Una seconda funzione che può essere definita in termini di \func{kill} è
-\func{killpg}, che è sostanzialmente equivalente a
-\code{kill(-pidgrp, signal)}; il suo prototipo è:
-\begin{prototype}{signal.h}{int killpg(pid\_t pidgrp, int signal)}
-
- Invia il segnale \param{signal} al process group \param{pidgrp}.
- \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, gli errori sono gli stessi di \func{kill}.}
-\end{prototype}
-e che permette di inviare un segnale a tutto un \textit{process group} (vedi
-\secref{sec:sess_proc_group}).
-
Solo l'amministratore può inviare un segnale ad un processo qualunque, in
-tutti gli altri casi l'userid reale o l'userid effettivo del processo
-chiamante devono corrispondere all'userid reale o all'userid salvato della
+tutti gli altri casi l'user-ID reale o l'user-ID effettivo del processo
+chiamante devono corrispondere all'user-ID reale o all'user-ID salvato della
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.
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.
Un caso particolare di segnali generati a richiesta è quello che riguarda i
vari segnali di temporizzazione e \const{SIGABRT}, per ciascuno di questi
segnali sono previste funzioni specifiche che ne effettuino l'invio. La più
-comune delle funzioni usate per la temporizzazione è \func{alarm} il cui
+comune delle funzioni usate per la temporizzazione è \funcd{alarm} il cui
prototipo è:
\begin{prototype}{unistd.h}{unsigned int alarm(unsigned int seconds)}
Predispone l'invio di \const{SIGALRM} dopo \param{seconds} secondi.
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 \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:
\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
- \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}
può specificare intervalli di tempo con precisione maggiore del secondo e
genera il segnale una sola volta.
-Per ovviare a questi limiti Linux deriva da BSD la funzione \func{setitimer}
+Per ovviare a questi limiti Linux deriva da BSD la funzione \funcd{setitimer}
che permette di usare un timer qualunque e l'invio di segnali periodici, al
costo però di una maggiore complessità d'uso e di una minore portabilità. Il
suo prototipo è:
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
errore, nel qual caso \var{errno} assumerà uno dei valori \errval{EINVAL} o
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
\label{tab:sig_setitimer_values}
\end{table}
-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 \type{itimerval}, definita in \figref{fig:file_stat_struct}.
+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 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
-scadenza. Entrambi esprimono i tempi tramite una struttura \var{timeval} che
+scadenza. Entrambi esprimono i tempi tramite una struttura \struct{timeval} che
permette una precisione fino al microsecondo.
Ciascun timer decrementa il valore di \var{it\_value} fino a zero, poi invia
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
- \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
-struct itimerval
-{
- struct timeval it_interval; /* next value */
- struct timeval it_value; /* current value */
-};
- \end{lstlisting}
+ \includestruct{listati/itimerval.h}
\end{minipage}
\normalsize
- \caption{La struttura \type{itimerval}, che definisce i valori dei timer di
- sistema.}
+ \caption{La struttura \structd{itimerval}, che definisce i valori dei timer
+ di sistema.}
\label{fig:sig_itimerval}
\end{figure}
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
\begin{minipage}[c]{15cm}
- \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
-unsigned int alarm(unsigned int seconds)
-{
- struct itimerval old, new;
- new.it_interval.tv_usec = 0;
- new.it_interval.tv_sec = 0;
- new.it_value.tv_usec = 0;
- new.it_value.tv_sec = (long int) seconds;
- if (setitimer(ITIMER_REAL, &new, &old) < 0) {
- return 0;
- }
- else {
- return old.it_value.tv_sec;
- }
-}
- \end{lstlisting}
+ \includestruct{listati/alarm_def.c}
\end{minipage}
\normalsize
\caption{Definizione di \func{alarm} in termini di \func{setitimer}.}
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
valore corrente di un timer senza modificarlo, è possibile usare la funzione
-\func{getitimer}, il cui prototipo è:
+\funcd{getitimer}, il cui prototipo è:
\begin{prototype}{sys/time.h}{int getitimer(int which, struct
itimerval *value)}
- Legge in \param{value} il valore del timer specificato da \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
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 è \func{abort};
-che, come accennato in \ref{sec:proc_termination}, permette di abortire
+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 è:
\begin{prototype}{stdlib.h}{void abort(void)}
\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 \func{pause} e \func{sleep}}
+\subsection{Le funzioni di pausa e attesa}
\label{sec:sig_pause_sleep}
-Il metodo tradizionale per fare attendere\footnote{cioè di porre
- temporaneamente il processo in stato di \textit{sleep}, vedi
- \ref{sec:proc_sched}.} ad un processo fino all'arrivo di un segnale è
-quello di usare la funzione \func{pause}, il cui prototipo è:
+Sono parecchie le occasioni in cui si può avere necessità di sospendere
+temporaneamente l'esecuzione di un processo. Nei sistemi più elementari in
+genere questo veniva fatto con un opportuno loop di attesa, ma in un sistema
+multitasking un loop di attesa è solo un inutile spreco di CPU, per questo ci
+sono apposite funzioni che permettono di mettere un processo in stato di
+attesa.\footnote{si tratta in sostanza di funzioni che permettono di portare
+ esplicitamente il processo in stato di \textit{sleep}, vedi
+ sez.~\ref{sec:proc_sched}.}
+
+Il metodo tradizionale per fare attendere ad un processo fino all'arrivo di un
+segnale è quello di usare la funzione \funcd{pause}, il cui prototipo è:
\begin{prototype}{unistd.h}{int pause(void)}
Pone il processo in stato di sleep fino al ritorno di un gestore.
La funzione segnala sempre una condizione di errore (il successo sarebbe
quello di aspettare indefinitamente). In genere si usa questa funzione quando
si vuole mettere un processo in attesa di un qualche evento specifico che non
-è sotto il suo diretto controllo (ad esempio la si può usare per far reagire
-il processo ad un segnale inviato da un altro processo).
+è sotto il suo diretto controllo (ad esempio la si può usare per interrompere
+l'esecuzione del processo fino all'arrivo di un segnale inviato da un altro
+processo).
-Se invece si vuole fare attendere un processo per un determinato intervallo di
-tempo nello standard POSIX.1 viene definita la funzione \func{sleep}, il cui
-prototipo è:
+Quando invece si vuole fare attendere un processo per un intervallo di tempo
+già noto nello standard POSIX.1 viene definita la funzione \funcd{sleep}, il
+cui prototipo è:
\begin{prototype}{unistd.h}{unsigned int sleep(unsigned int seconds)}
Pone il processo in stato di sleep per \param{seconds} secondi.
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.
-La granularità di \func{sleep} permette di specificare attese in secondi, per
-questo sia sotto BSD4.3 che in SUSv2 è stata definita la funzione
-\func{usleep} (dove la \texttt{u} è intesa come sostituzione di $\mu$); i due
+La granularità di \func{sleep} permette di specificare attese soltanto in
+secondi, per questo sia sotto BSD4.3 che in SUSv2 è stata definita la funzione
+\funcd{usleep} (dove la \texttt{u} è intesa come sostituzione di $\mu$); i due
standard hanno delle definizioni diverse, ma le \acr{glibc}
seguono\footnote{secondo la pagina di manuale almeno dalla versione 2.2.2.}
seguono quella di SUSv2 che prevede il seguente prototipo:
Anche questa funzione, a seconda delle implementazioni, può presentare
problemi nell'interazione con \func{alarm} e \const{SIGALRM}. È pertanto
-deprecata in favore della funzione \func{nanosleep}, definita dallo standard
+deprecata in favore della funzione \funcd{nanosleep}, definita dallo standard
POSIX1.b, il cui prototipo è:
\begin{prototype}{unistd.h}{int nanosleep(const struct timespec *req, struct
timespec *rem)}
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
-delle strutture di tipo \var{timespec}, la cui definizione è riportata in
-\figref{fig:sys_timeval_struct}, che permettono di specificare un tempo con
+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.
La funzione risolve anche il problema di proseguire l'attesa dopo
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{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\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}.
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.
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
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}.
-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}.
-% è 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
- \begin{lstlisting}{}
-void HandSigCHLD(int sig)
-{
- int errno_save;
- int status;
- pid_t pid;
- /* save errno current value */
- errno_save = errno;
- /* loop until no */
- do {
- errno = 0;
- pid = waitpid(WAIT_ANY, &status, WNOHANG);
- if (pid > 0) {
- debug("child %d terminated with status %x\n", pid, status);
- }
- } while ((pid > 0) && (errno == EINTR));
- /* restore errno value */
- errno = errno_save;
- /* return */
- return;
-}
- \end{lstlisting}
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/hand_sigchild.c}
+ \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 \secref{sec:sys_errno}) si
-comincia (\texttt{\small 12-13}) con il salvare lo stato corrente di
+programmazione (si ricordi quanto accennato sez.~\ref{sec:sys_errno}) si
+comincia (\texttt{\small 6--7}) con il salvare lo stato corrente di
\var{errno}, in modo da poterlo ripristinare prima del ritorno del gestore
-(\texttt{\small 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 generazione di ulteriori segnali dello stesso tipo. In questo caso
-normalmente i segnali segnali successivi vengono ``fusi'' col primo ed al
-processo ne viene recapitato soltanto uno.
+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 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
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
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.
\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{race condition} che i segnali possono generare e alla natura
-asincrona degli stessi.
+condition\index{\textit{race~condition}} che i segnali possono generare e alla
+natura asincrona degli stessi.
Affronteremo queste problematiche in questa sezione, partendo da un esempio
che le evidenzi, per poi prendere in esame le varie funzioni che permettono di
\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
-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]
- \footnotesize
- \begin{lstlisting}{}
-void alarm_hand(int sig) {
- /* check if the signal is the right one */
- if (sig != SIGALRM) { /* if not exit with error */
- printf("Something wrong, handler for SIGALRM\n");
- exit(1);
- } else { /* do nothing, just interrupt pause */
- return;
- }
-}
-unsigned int sleep(unsigned int seconds)
-{
- sighandler_t prev_handler;
- /* install and check new handler */
- if ((prev_handler = signal(SIGALRM, alarm_hand)) == SIG_ERR) {
- printf("Cannot set handler for alarm\n");
- exit(-1);
- }
- /* set alarm and go to sleep */
- alarm(seconds);
- pause();
- /* restore previous signal handler */
- signal(SIGALRM, prev_handler);
- /* return remaining time */
- return alarm(0);
-}
- \end{lstlisting}
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/sleep_danger.c}
+ \end{minipage}
\normalsize
\caption{Una implementazione pericolosa di \func{sleep}.}
\label{fig:sig_sleep_wrong}
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{race condition}. Infatti se il
-processo viene interrotto fra la chiamata di \func{alarm} e \func{pause} può
-capitare (ad esempio se il sistema è molto carico) che il tempo di attesa
-scada prima dell'esecuzione quest'ultima, cosicché essa sarebbe eseguita dopo
-l'arrivo di \const{SIGALRM}. In questo caso ci si troverebbe di fronte ad un
-deadlock\index{deadlock}, in quanto \func{pause} non verrebbe mai più
-interrotta (se non in caso di un altro segnale).
+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 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).
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
- \begin{lstlisting}{}
-static jmp_buff alarm_return;
-unsigned int sleep(unsigned int seconds)
-{
- signandler_t prev_handler;
- if ((prev_handler = signal(SIGALRM, alarm_hand)) == SIG_ERR) {
- printf("Cannot set handler for alarm\n");
- exit(1);
- }
- if (setjmp(alarm_return) == 0) { /* if not returning from handler */
- alarm(second); /* call alarm */
- pause(); /* then wait */
- }
- /* restore previous signal handler */
- signal(SIGALRM, prev_handler);
- /* remove alarm, return remaining time */
- return alarm(0);
-}
-void alarm_hand(int sig)
-{
- /* check if the signal is the right one */
- if (sig != SIGALRM) { /* if not exit with error */
- printf("Something wrong, handler for SIGALRM\n");
- exit(1);
- } else { /* return in main after the call to pause */
- longjump(alarm_return, 1);
- }
-}
- \end{lstlisting}
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/sleep_defect.c}
+ \end{minipage}
\normalsize
\caption{Una implementazione ancora malfunzionante di \func{sleep}.}
\label{fig:sig_sleep_incomplete}
\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
+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
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
- \begin{lstlisting}{}
-sig_atomic_t flag;
-int main()
-{
- flag = 0;
- ...
- if (flag) { /* test if signal occurred */
- flag = 0; /* reset flag */
- do_response(); /* do things */
- } else {
- do_other(); /* do other things */
- }
- ...
-}
-void alarm_hand(int sig)
-{
- /* set the flag
- flag = 1;
- return;
-}
- \end{lstlisting}
+ \footnotesize\centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/sig_alarm.c}
+ \end{minipage}
\normalsize
\caption{Un esempio non funzionante del codice per il controllo di un
evento generato da un segnale.}
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
+Questo è il tipico esempio di caso, già citato in
+sez.~\ref{sec:proc_race_cond}, in cui si genera una
+\index{\textit{race~condition}}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.
\subsection{Gli \textsl{insiemi di segnali} o \textit{signal set}}
\label{sec:sig_sigset}
+\index{\textit{signal~set}|(}
Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali
-dei primi Unix, nate con la semantica inaffidabile, hanno dei limiti non
+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.
-
+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
+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: \func{sigemptyset}, \func{sigfillset},
-\func{sigaddset}, \func{sigdelset} e \func{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}
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}
permette di verificare la presenza di uno specifico segnale in un
insieme.
+\index{\textit{signal~set}|)}
+
\subsection{La funzione \func{sigaction}}
\label{sec:sig_sigaction}
-La funzione principale dell'interfaccia standard POSIX.1 per i segnali è
-\func{sigaction}, essa ha sostanzialemente lo stesso uso di \func{signal},
+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.
+
+La funzione principale dell'interfaccia POSIX.1 per i segnali è
+\funcd{sigaction}. Essa ha sostanzialmente lo stesso uso di \func{signal},
permette cioè di specificare le modalità con cui un segnale può essere gestito
da un processo. Il suo prototipo è:
\begin{prototype}{signal.h}{int sigaction(int signum, const struct sigaction
nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
che non consente di ottenere l'azione corrente senza installarne una nuova.
-Entrambi i puntatori fanno riferimento alla struttura \var{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
+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 fig.~\ref{fig:sig_sigaction}. Il campo
\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
più usato.
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
- \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
-struct sigaction
-{
- void (*sa_handler)(int);
- void (*sa_sigaction)(int, siginfo_t *, void *);
- sigset_t sa_mask;
- int sa_flags;
- void (*sa_restorer)(void);
-}
- \end{lstlisting}
+ \includestruct{listati/sigaction.h}
\end{minipage}
\normalsize
- \caption{La struttura \var{sigaction}.}
+ \caption{La struttura \structd{sigaction}.}
\label{fig:sig_sigaction}
\end{figure}
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
\const{SA\_RESTART} & Riavvia automaticamente le \textit{slow system
call} quando vengono interrotte dal suddetto
segnale; riproduce cioè il comportamento standard
- di BSD.\\
+ di BSD.\index{system~call~lente}\\
\const{SA\_NOMASK} & Evita che il segnale corrente sia bloccato durante
l'esecuzione del gestore.\\
\const{SA\_NODEFER} & Sinonimo di \const{SA\_NOMASK}.\\
\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 \var{sigaction}.}
+ \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}
-permette\footnote{La possibilità è prevista dallo standard POSIX.1b, ed è
- stata aggiunta nei kernel della serie 2.1.x con l'introduzione dei segnali
- real-time (vedi \secref{sec:sig_real_time}). In precedenza era possibile
- ottenere alcune informazioni addizionali usando \var{sa\_handler} con un
- secondo parametro addizionale di tipo \var{struct sigcontext}, che adesso è
- deprecato.} di utilizzare due forme diverse di gestore, da
+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},
-(che devono essere usati in maniera alternativa, in certe implementazioni
-questi vengono addirittura definiti come \ctyp{union}): la prima è quella
-classica usata anche con \func{signal}, la seconda permette invece di usare un
-gestore in grado di ricevere informazioni più dettagliate dal sistema,
-attraverso la struttura \type{siginfo\_t}, riportata in
-\figref{fig:sig_siginfo_t}.
+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
\begin{minipage}[c]{15cm}
- \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
-siginfo_t {
- int si_signo; /* Signal number */
- int si_errno; /* An errno value */
- int si_code; /* Signal code */
- pid_t si_pid; /* Sending process ID */
- uid_t si_uid; /* Real user ID of sending process */
- int si_status; /* Exit value or signal */
- clock_t si_utime; /* User time consumed */
- clock_t si_stime; /* System time consumed */
- sigval_t si_value; /* Signal value */
- int si_int; /* POSIX.1b signal */
- void * si_ptr; /* POSIX.1b signal */
- void * si_addr; /* Memory location which caused fault */
- int si_band; /* Band event */
- int si_fd; /* File descriptor */
-}
- \end{lstlisting}
+ \includestruct{listati/siginfo_t.h}
\end{minipage}
\normalsize
- \caption{La struttura \type{siginfo\_t}.}
+ \caption{La struttura \structd{siginfo\_t}.}
\label{fig:sig_siginfo_t}
\end{figure}
maggiori dettagli riguardo l'errore (come il tipo di errore aritmetico, di
istruzione illecita o di violazione di memoria) mentre alcuni segnali di
controllo (\const{SIGCHLD}, \const{SIGTRAP} e \const{SIGPOLL}) forniscono
-altre informazioni speecifiche. In tutti i casi il valore del campo è
+altre informazioni specifiche. In tutti i casi il valore del campo è
riportato attraverso delle costanti (le cui definizioni si trovano
\file{bits/siginfo.h}) il cui elenco dettagliato è disponibile nella pagina di
-manuale di di \func{sigaction}.
+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})
-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
interagire in maniera anomala. Infatti l'azione specificata con
-\var{sigaction} contiene un maggior numero di informazioni rispetto al
-semplice indirizzo del gestore restituito da \func{signal}. Per questo
-motivo se si usa quest'ultima per installare un gestore sostituendone uno
+\struct{sigaction} contiene un maggior numero di informazioni rispetto al
+semplice indirizzo del gestore restituito da \func{signal}. Per questo motivo
+se si usa quest'ultima per installare un gestore sostituendone uno
precedentemente installato con \func{sigaction}, non sarà possibile effettuare
un ripristino corretto dello stesso.
sempre il caso di evitare l'uso di \func{signal} a favore di \func{sigaction}.
\begin{figure}[!htb]
- \footnotesize
- \begin{lstlisting}{}
-typedef void SigFunc(int);
-inline SigFunc * Signal(int signo, SigFunc *func)
-{
- struct sigaction new_handl, old_handl;
- new_handl.sa_handler = func;
- /* clear signal mask: no signal blocked during execution of func */
- if (sigemptyset(&new_handl.sa_mask)!=0){ /* initialize signal set */
- return SIG_ERR;
- }
- new_handl.sa_flags=0; /* init to 0 all flags */
- /* change action for signo signal */
- if (sigaction(signo, &new_handl, &old_handl)){
- return SIG_ERR;
- }
- return (old_handl.sa_handler);
-}
- \end{lstlisting}
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/Signal.c}
+ \end{minipage}
\normalsize
- \caption{Una funzione equivalente a \func{signal} definita attraverso
- \func{sigaction}.}
+ \caption{La funzione \func{Signal}, equivalente a \func{signal}, definita
+ attraverso \func{sigaction}.}
\label{fig:sig_Signal_code}
\end{figure}
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
-
-
\subsection{La gestione della \textsl{maschera dei segnali} o
\textit{signal mask}}
\label{sec:sig_sigmask}
-Come spiegato in \secref{sec:sig_semantics} tutti i moderni sistemi unix-like
-permettono si bloccare temporaneamente (o di eliminare completamente,
+\index{\textit{signal mask}|(}
+Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like
+permettono di bloccare temporaneamente (o di eliminare completamente,
impostando \const{SIG\_IGN} come azione) la consegna dei segnali ad un
processo. Questo è fatto specificando la cosiddetta \textsl{maschera dei
segnali} (o \textit{signal mask}) del processo\footnote{nel caso di Linux
- essa è mantenuta dal campo \var{blocked} della \var{task\_struct} del
+ 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 \var{sigaction}.
+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.
+che essi siano eseguite senza interruzioni.
Le operazioni più semplici, come l'assegnazione o il controllo di una
variabile (per essere sicuri si può usare il tipo \type{sig\_atomic\_t}) di
norma sono atomiche, quando occorrono operazioni più complesse si può invece
-usare la funzione \func{sigprocmask} che permette di bloccare uno o più
+usare la funzione \funcd{sigprocmask} che permette di bloccare uno o più
segnali; il suo prototipo è:
\begin{prototype}{signal.h}
{int sigprocmask(int how, const sigset\_t *set, sigset\_t *oldset)}
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ò
perduta alla conclusione del terminatore.
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è
-la possibilità che il processo riceva il segnale che si intende usare per
+dei casi di race condition\index{\textit{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
uscire dallo stato di attesa invocato con \func{pause} immediatamente prima
dell'esecuzione di quest'ultima. Per poter effettuare atomicamente la modifica
della maschera dei segnali (di solito attivandone uno specifico) insieme alla
sospensione del processo lo standard POSIX ha previsto la funzione
-\func{sigsuspend}, il cui prototipo è:
+\funcd{sigsuspend}, il cui prototipo è:
\begin{prototype}{signal.h}
{int sigsuspend(const sigset\_t *mask)}
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]
- \footnotesize
- \begin{lstlisting}{}
-void alarm_hand(int);
-unsigned int sleep(unsigned int seconds)
-{
- struct sigaction new_action, old_action;
- sigset_t old_mask, stop_mask, sleep_mask;
- /* set the signal handler */
- sigemptyset(&new_action.sa_mask); /* no signal blocked */
- new_action.sa_handler = alarm_hand; /* set handler */
- new_action.sa_flags = 0; /* no flags */
- sigaction(SIGALRM, &new_action, &old_action); /* install action */
- /* block SIGALRM to avoid race conditions */
- sigemptyset(&stop_mask); /* init mask to empty */
- sigaddset(&stop_mask, SIGALRM); /* add SIGALRM */
- sigprocmask(SIG_BLOCK, &stop_mask, &old_mask); /* add SIGALRM to blocked */
- /* send the alarm */
- alarm(seconds);
- /* going to sleep enabling SIGALRM */
- sleep_mask = old_mask; /* take mask */
- sigdelset(&sleep_mask, SIGALRM); /* remove SIGALRM */
- sigsuspend(&sleep_mask); /* go to sleep */
- /* restore previous settings */
- sigprocmask(SIG_SETMASK, &old_mask, NULL); /* reset signal mask */
- sigaction(SIGALRM, &old_action, NULL); /* reset signal action */
- /* return remaining time */
- return alarm(0);
-}
-void alarm_hand(int sig)
-{
- return; /* just return to interrupt sigsuspend */
-}
- \end{lstlisting}
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/sleep.c}
+ \end{minipage}
\normalsize
\caption{Una implementazione completa di \func{sleep}.}
\label{fig:sig_sleep_ok}
\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 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{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:
+In questo modo non sono più possibili race
+condition\index{\textit{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{deadlock} dovuto all'arrivo del segnale prima dell'esecuzione
-di \func{sigsuspend}.
+deadlock\index{\textit{deadlock}} dovuto all'arrivo del segnale prima
+dell'esecuzione di \func{sigsuspend}.
+\index{\textit{signal mask}|)}
\subsection{Ulteriori funzioni di gestione}
\label{sec:sig_specific_features}
-In questa ultimo paragrafo esamineremo varie funzioni di gestione dei segnali
-non descritte finora, relative agli aspetti meno utilizzati. La prima di esse
-è \func{sigpending}, anch'essa introdotta dallo standard POSIX.1; il suo
-prototipo è:
+In questo ultimo paragrafo esamineremo le rimanenti funzioni di gestione dei
+segnali non descritte finora, relative agli aspetti meno utilizzati e più
+``\textsl{esoterici}'' della interfaccia.
+
+La prima di queste funzioni è \funcd{sigpending}, anch'essa introdotta dallo
+standard POSIX.1; il suo prototipo è:
\begin{prototype}{signal.h}
{int sigpending(sigset\_t *set)}
\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
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*}
+\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 \tabref{tab:sig_sa_flag}) per
- dire al sistema di usare lo stack alternativo durante l'esecuzione del
- gestore.
-\end{enumerate*}
+ 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
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. 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.
-
-Come accennato per poter essere usato lo stack per i segnali deve essere
-indicato al sistema attraverso la funzione \func{sigaltstack}; il suo
+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.
+
+Come accennato, per poter essere usato, lo 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)}
\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).
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
- \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
-typedef struct {
- void *ss_sp; /* Base address of stack */
- int ss_flags; /* Flags */
- size_t ss_size; /* Number of bytes in stack */
-} stack_t;
- \end{lstlisting}
+ \includestruct{listati/stack_t.h}
\end{minipage}
\normalsize
- \caption{La struttura \var{stack\_t}.}
+ \caption{La struttura \structd{stack\_t}.}
\label{fig:sig_stack_t}
\end{figure}
-Il campo \var{ss\_sp} di \var{stack\_t} indica l'indirizzo base dello stack,
+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
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)}.
+limite 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 stack alternativo.
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
Resta quindi il problema di cosa succede alla maschera dei segnali quando si
esce da un gestore usando questa funzione. Il comportamento dipende
-dall'implementazione; in particolare BSD ripristina la maschera dei segnali
-precedente l'invocazione, come per un normale ritorno, mentre System V no. Lo
-standard POSIX.1 non specifica questo comportamento per \func{setjmp} e
+dall'implementazione; in particolare BSD prevede che sia ripristinata la
+maschera dei segnali precedente l'invocazione, come per un normale ritorno,
+mentre System V no.
+
+Lo standard POSIX.1 non specifica questo comportamento per \func{setjmp} e
\func{longjmp}, 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
-\func{sigsetjmp} e \func{siglongjmp}, che permettono di decidere quale dei due
-comportamenti il programma deve assumere; i loro prototipi sono:
+\funcd{sigsetjmp} e \funcd{siglongjmp}, che permettono di decidere quale dei
+due comportamenti il programma deve assumere; i loro prototipi sono:
\begin{functions}
\headdecl{setjmp.h}
\funcdecl{int sigsetjmp(sigjmp\_buf env, int savesigs)} Salva il contesto
- dello stack per un salto non locale.
+ dello stack per un salto non-locale\index{salto~non-locale}.
- \funcdecl{void siglongjmp(sigjmp\_buf env, int val)} Esegue un salto non
- locale su un precedente contesto.
+ \funcdecl{void siglongjmp(sigjmp\_buf env, int val)} Esegue un salto
+ 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}
Le due funzioni prendono come primo argomento la variabile su cui viene
-salvato il contesto dello stack per permettere il 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 maschera dei segnali.
+salvato il contesto dello 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
introdotta in Linux a partire dal kernel 2.1.43(?), e dalle \acr{glibc}
2.1(?).} in particolare sono stati superati tre limiti fondamentali dei
segnali classici:
-\begin{description}
+\begin{basedescript}{\desclabelwidth{1cm}\desclabelstyle{\nextlinelabel}}
\item[I segnali non sono accumulati]
-
se più segnali vengono generati prima dell'esecuzione di un gestore
questo sarà eseguito una sola volta, ed il processo non sarà in grado di
- accorgersi di quante volte l'evento che ha generato il segnale è accaduto.
-\item[I segnali non trasportano informazione]
-
- i segnali classici non prevedono prevedono altra informazione sull'evento
+ 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
certi segnali ha la precedenza rispetto ad altri.
-\end{description}
+\end{basedescript}
Per poter superare queste limitazioni lo standard ha introdotto delle nuove
caratteristiche, che sono state associate ad una nuova classe di segnali, che
-vengono chiamati \textsl{segnali real-time}, in particolare:
+vengono chiamati \textsl{segnali real-time}, in particolare le funzionalità
+aggiunte sono:
-\begin{itemize*}
+\begin{enumerate}
\item i segnali sono inseriti in una coda che permette di consegnare istanze
multiple dello stesso segnale qualora esso venga inviato più volte prima
dell'esecuzione del gestore; si assicura così che il processo riceva un
\item è stata introdotta una priorità nella consegna dei segnali: i segnali
vengono consegnati in ordine a seconda del loro valore, partendo da quelli
con un numero minore, che pertanto hanno una priorità maggiore.
-\item è stata introdotta la possibilità di restituire dei dati al
- gestore, attraverso l'uso di un campo apposito nella struttura
- \type{siginfo\_t} accessibile tramite gestori di tipo
+\item è stata introdotta la possibilità di restituire dei dati al gestore,
+ attraverso l'uso di un apposito campo \var{si\_value} nella struttura
+ \struct{siginfo\_t}, accessibile tramite gestori di tipo
\var{sa\_sigaction}.
-\end{itemize*}
+\end{enumerate}
-Queste nuove caratteristiche (eccetto l'ultima, che, come visto in
-\secref{sec:sig_sigaction}, è parzialmente disponibile anche con i segnali
-ordinari) si applicano solo ai nuovi segnali real-time; questi ultimi sono
-accessibili in un range di valori specificati dalle due macro \const{SIGRTMIN}
-e \const{SIGRTMAX},\footnote{in Linux di solito il primo valore è 32, ed il
- secondo \code{\_NSIG-1}, che di norma è 63, per un totale di 32 segnali
- disponibili, contro gli almeno 8 richiesti da POSIX.1b.} che specificano il
-numero minimo e massimo associato ad un segnale real-time.
+Queste nuove funzionalità (eccetto l'ultima, che, come vedremo, è parzialmente
+disponibile anche con i segnali ordinari) si applicano solo ai nuovi segnali
+real-time; questi ultimi sono accessibili in un range di valori specificati
+dalle due macro \const{SIGRTMIN} e \const{SIGRTMAX},\footnote{in Linux di
+ solito (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
real-time.
Si tenga presente che questi nuovi segnali non sono associati a nessun evento
-sepcifico (a meno di non utilizzarli, come vedremo in
-\secref{sec:file_asyncronous_io}, per l'I/O asincrono) e devono essere inviati
-esplicitamente. Tutti i segnali real-time restituiscono al gestore, oltre
-ai campi \var{si\_pid} e \var{si\_uid} di \type{siginfo\_t} una struttura
-\type{sigval} (riportata in \figref{fig:sig_sigval}) in cui può essere
-restituito al processo un valore o un indirizzo, che costituisce il meccanismo
-con cui il segnale è in grado di inviare una ulteriore informazione al
-processo.
+specifico, a meno di non utilizzarli in meccanismi di notifica come quelli per
+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 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 è 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
+\var{si\_uid} in cui vengono memorizzati rispettivamente il \acr{pid} e
+l'user-ID effettivo del processo che ha inviato il segnale, mentre per la
+restituzione dei dati viene usato il campo \var{si\_value}.
+
+Questo è una \ctyp{union} di tipo \struct{sigval\_t} (la sua definizione è in
+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
+ 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]
\footnotesize \centering
\begin{minipage}[c]{15cm}
- \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
-union sigval {
- int sival_int;
- void *sival_ptr;
-}
- \end{lstlisting}
+ \includestruct{listati/sigval_t.h}
\end{minipage}
\normalsize
- \caption{La struttura \type{sigval}, usata dai segnali real time per
- restituire dati al gestore.}
+ \caption{La unione \structd{sigval\_t}.}
\label{fig:sig_sigval}
\end{figure}
-A causa di queste loro caratteristiche, la funzione \func{kill} non è adatta
-ad inviare un segnale real time, in quanto non è in grado di fornire alcun
-valore per \var{sigval}; per questo motivo lo standard ha previsto una nuova
-funzione, \func{sigqueue}, il cui prototipo è:
+A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
+inviare segnali real-time, poiché non è in grado di fornire alcun valore
+per \struct{sigval\_t}; per questo motivo lo standard ha previsto una nuova
+funzione, \funcd{sigqueue}, il cui prototipo è:
\begin{prototype}{signal.h}
- {int sigqueue(pid\_t pid, int signo, const union sigval value)}
+ {int sigqueue(pid\_t pid, int signo, const sigval\_t value)}
Invia il segnale \param{signo} al processo \param{pid}, restituendo al
gestore il valore \param{value}.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EAGAIN}] La coda è esarita, ci sono già \const{SIGQUEUE\_MAX}
+ \item[\errcode{EAGAIN}] La coda è esaurita, ci sono già \const{SIGQUEUE\_MAX}
segnali in attesa si consegna.
\item[\errcode{EPERM}] Non si hanno privilegi appropriati per inviare il
segnale al processo specificato.
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 è
-installato un gestore con \const{SA\_SIGINFO} e ci sono risorse
-disponibili, vale a dire che c'è posto nella coda\footnote{la profondità della
- coda è indicata dalla costante \const{SIGQUEUE\_MAX}, una della tante
- costanti di sistema definite dallo standard POSIX, che non abbiamo riportato
- esplicitamente in \secref{sec:sys_limits}. Il suo valore minimo secondo lo
- standard, \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32.}, esso viene inserito
-e diventa pendente; una volta consegnato riporterà nel campo \var{si\_code} di
-\var{siginfo} il valore \const{SI\_QUEUE} e il campo \var{si\_value} riceverà
-quanto inviato con \param{value}. Se invece si è installato un gestore
-nella forma classica il segnale sarà generato, ma tutte le caratteristiche
-tipiche dei segnali real-time (priorità e coda) saranno perse.
+installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili,
+(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,
+ \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 è
+ di 1024.} nella coda dei segnali real-time) esso viene inserito e diventa
+pendente; una volta consegnato riporterà nel campo \var{si\_code} di
+\struct{siginfo\_t} il valore \const{SI\_QUEUE} e il campo \var{si\_value}
+riceverà quanto inviato con \param{value}. Se invece si è installato un
+gestore nella forma classica il segnale sarà generato, ma tutte le
+caratteristiche tipiche dei segnali real-time (priorità e coda) saranno perse.
Lo standard POSIX.1b definisce inoltre delle nuove funzioni che permettono di
gestire l'attesa di segnali specifici su una coda, esse servono in particolar
modo nel caso dei thread, in cui si possono usare i segnali real-time come
meccanismi di comunicazione elementare; la prima di queste funzioni è
-\func{sigwait}, il cui prototipo è:
+\funcd{sigwait}, il cui prototipo è:
\begin{prototype}{signal.h}
{int sigwait(const sigset\_t *set, int *sig)}
prevedibile.
Lo standard POSIX.1b definisce altre due funzioni, anch'esse usate
-prevalentemente con i thread; \func{sigwaitinfo} e \func{sigtimedwait}, i
+prevalentemente con i thread; \funcd{sigwaitinfo} e \funcd{sigtimedwait}, i
relativi prototipi sono:
\begin{functions}
\headdecl{signal.h}
\func{sigwait}, ai quali si aggiunge, per \func{sigtimedwait}:
\begin{errlist}
\item[\errcode{EAGAIN}] Si è superato il timeout senza che un segnale atteso
- fosse emmesso.
+ fosse emesso.
\end{errlist}
}
\end{functions}
La seconda è identica alla prima ma in più permette di specificare un timeout,
scaduto il quale ritornerà con un errore. Se si specifica un puntatore nullo
il comportamento sarà identico a \func{sigwaitinfo}, se si specifica un tempo
-di timeout nullo, e non ci sono sengali pendenti la funzione ritornerà
+di timeout nullo, e non ci sono segnali pendenti la funzione ritornerà
immediatamente; in questo modo si può eliminare un segnale dalla coda senza
dover essere bloccati qualora esso non sia presente.
-
L'uso di queste funzioni è principalmente associato alla gestione dei segnali
com i thread. In genere esse vengono chiamate dal thread incaricato della
gestione, che al ritorno della funzione esegue il codice che usualmente
questa maniera devono essere mascherati per tutti i thread, compreso quello
dedicato alla gestione, che potrebbe riceverlo fra due chiamate successive.
+
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
projects / gapil.git / blobdiff