%% signal.tex
%%
-%% Copyright (C) 2000-2011 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2012 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 "Un preambolo",
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 funzione di gestione
-(quello che da qui in avanti chiameremo il \textsl{gestore} del segnale,
-dall'inglese \textit{signal handler}) che può essere stata specificata
-dall'utente (nel qual caso si dice che si \textsl{intercetta} il segnale).
+viene eseguita una azione predefinita o una apposita funzione di gestione che
+può essere stata specificata dall'utente, nel qual caso si dice che si
+\textsl{intercetta} il segnale. Riprendendo la terminologia originale da qui
+in avanti faremo riferimento a questa funzione come al \textsl{gestore} del
+segnale, traduzione approssimata dell'inglese \textit{signal handler}.
\subsection{Le \textsl{semantiche} del funzionamento dei segnali}
affidabile} (o \textit{reliable}) e \textsl{semantica inaffidabile} (o
\textit{unreliable}).
-Nella \textsl{semantica inaffidabile} (quella implementata dalle prime
-versioni di Unix) la funzione di gestione del segnale specificata dall'utente
-non resta attiva una volta che è stata eseguita; è perciò compito dell'utente
-stesso ripetere l'installazione all'interno del \textsl{gestore} del segnale,
-in tutti quei casi in cui si vuole che esso resti attivo.
-
-In questo caso è possibile una situazione in cui i segnali possono essere
-perduti. Si consideri il segmento di codice riportato in
-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
-reinstallazione, verrà eseguito il comportamento predefinito assegnato al
-segnale stesso, il che può comportare, a seconda dei casi, che il segnale
-viene perso (se l'impostazione predefinita era quello di ignorarlo) o la
-terminazione immediata del processo; in entrambi i casi l'azione prevista non
-verrà eseguita.
+Nella \textsl{semantica inaffidabile}, che veniva implementata dalle prime
+versioni di Unix, la funzione di gestione del segnale specificata dall'utente
+non restava attiva una volta che era stata eseguita; era perciò compito
+dell'utente ripetere l'installazione dello stesso all'interno del
+\textsl{gestore} del segnale in tutti quei casi in cui si voleva che esso
+restasse attivo.
\begin{figure}[!htbp]
\footnotesize \centering
\label{fig:sig_old_handler}
\end{figure}
+In questo caso però è possibile una situazione in cui i segnali possono essere
+perduti. Si consideri il segmento di codice riportato in
+fig.~\ref{fig:sig_old_handler}: nel programma principale viene installato un
+gestore (\texttt{\small 5}), la cui prima operazione (\texttt{\small 11}) è
+quella di reinstallare se stesso. Se nell'esecuzione del gestore fosse
+arrivato un secondo segnale prima che esso abbia potuto eseguire la
+reinstallazione di se stesso per questo secondo segnale verrebbe eseguito il
+comportamento predefinito, il che può comportare, a seconda dei casi, la
+perdita del segnale (se l'impostazione predefinita è quella di ignorarlo) o la
+terminazione immediata del processo; in entrambi i casi l'azione prevista dal
+gestore non verrebbe eseguita.
+
Questa è la ragione per cui l'implementazione dei segnali secondo questa
-semantica viene chiamata \textsl{inaffidabile}; infatti la ricezione del
+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 \itindex{race~condition} \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
-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.
+(si ricordi sez.~\ref{sec:proc_multi_prog}). Un altro problema è che in
+questa semantica non esiste un modo per bloccare i segnali quando non si vuole
+che arrivino; i processi possono ignorare il segnale, ma non è possibile
+istruire il sistema a non fare nulla in occasione di un segnale, pur
+mantenendo memoria del fatto che è avvenuto.
Nella semantica \textsl{affidabile} (quella utilizzata da Linux e da ogni Unix
moderno) il gestore una volta installato resta attivo e non si hanno tutti i
problemi precedenti. In questa semantica i segnali vengono \textsl{generati}
dal kernel per un processo all'occorrenza dell'evento che causa il segnale. In
-genere questo viene fatto dal kernel impostando l'apposito campo della
+genere questo viene fatto dal kernel impostando un apposito campo della
\struct{task\_struct} del processo nella \itindex{process~table}
\textit{process table} (si veda fig.~\ref{fig:proc_task_struct}).
\subsection{Tipi di segnali}
\label{sec:sig_types}
-In generale gli eventi che generano segnali si possono dividere in tre
-categorie principali: errori, eventi esterni e richieste esplicite.
+In generale si tende a classificare gli eventi che possono generare dei
+segnali in tre categorie principali: errori, eventi esterni e richieste
+esplicite.
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 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.
+codice di errore da parte di una funzione di libreria. Sono gli errori che
+possono avvenire nell'esecuzione delle istruzioni di un programma, come le
+divisioni per zero o l'uso di indirizzi di memoria non validi, che causano
+l'emissione di un segnale.
-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
-input, scadenze di un timer, terminazione di processi figli.
+Un evento esterno ha in genere a che fare con le operazioni di lettura e
+scrittura su file, o con l'interazione con dispositivi o con altri processi;
+esempi di segnali di questo tipo sono quelli legati all'arrivo di dati in
+ingresso, scadenze di un timer, terminazione di processi figli, la pressione
+dei tasti di stop o di suspend su un terminale.
-Una richiesta esplicita significa l'uso di una chiamata di sistema (come
-\func{kill} o \func{raise}) per la generazione di un segnale, cosa che
-viene fatta usualmente dalla shell quando l'utente invoca la sequenza di tasti
-di stop o di suspend, ma può essere pure inserita all'interno di un programma.
+Una richiesta esplicita significa l'uso da parte di un programma delle
+apposite funzioni di sistema (in sostanza \func{kill} o \func{raise}) per la
+generazione ``\textsl{manuale}'' di un segnale.
Si dice poi che i segnali possono essere \textsl{asincroni} o
\textsl{sincroni}. Un segnale \textsl{sincrono} è legato ad una azione
specifica di un programma ed è inviato (a meno che non sia bloccato) durante
-tale azione; molti errori generano segnali \textsl{sincroni}, così come la
+tale azione. Molti errori generano segnali \textsl{sincroni}, così come la
richiesta esplicita da parte del processo tramite le chiamate al sistema.
Alcuni errori come la divisione per zero non sono completamente sincroni e
possono arrivare dopo qualche istruzione.
non è quella di essere ignorato, il kernel prende nota del fatto nella
\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).
+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
\itindex{scheduler} scheduler che esegue l'azione specificata. Questo a meno
che il segnale in questione non sia stato bloccato prima della notifica, nel
qual caso l'invio non avviene ed il segnale resta \textsl{pendente}
-indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
-notificato. Si tenga presente però che i segnali \textsl{pendenti} non si
+indefinitamente.
+
+Quando lo si sblocca un segnale \textsl{pendente} sarà subito notificato. Si
+tenga presente però che tradizionalmente 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é 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
-segnale. Per alcuni segnali (\signal{SIGKILL} e \signal{SIGSTOP}) questa azione
-è fissa e non può essere cambiata, ma per tutti gli altri si può selezionare
-una delle tre possibilità seguenti:
+una sola volta. In realtà questo non vale nel caso dei cosiddetti segnali
+\textit{real-time}, che vedremo in sez.~\ref{sec:sig_real_time}, ma questa è
+una funzionalità avanzata che per ora tralasceremo.
+
+Si ricordi inoltre che se l'azione specificata per un segnale è quella di
+essere ignorato questo sarà scartato immediatamente al momento della sua
+generazione, e questo anche se in quel momento il segnale è bloccato, perché
+bloccare su un segnale significa bloccarne la notifica. Per questo motivo un
+segnale, 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
+segnale. Per alcuni segnali (per la precisione \signal{SIGKILL} e
+\signal{SIGSTOP}) questa azione è predeterminata dal kernel e non può essere
+mai modificata, ma per tutti gli altri si può selezionare una delle tre
+possibilità seguenti:
\begin{itemize*}
\item ignorare il segnale;
-\item catturare il segnale, ed utilizzare il gestore specificato;
+\item intercettare il segnale, ed utilizzare il gestore specificato;
\item accettare l'azione predefinita per quel segnale.
\end{itemize*}
Un programma può specificare queste scelte usando le due funzioni
-\func{signal} e \func{sigaction} (vedi sez.~\ref{sec:sig_signal} e
-sez.~\ref{sec:sig_sigaction}). Se si è installato un gestore sarà quest'ultimo
-ad essere eseguito alla notifica del segnale. Inoltre il sistema farà si che
-mentre viene eseguito il gestore di un segnale, quest'ultimo venga
-automaticamente bloccato (così si possono evitare \itindex{race~condition}
-\textit{race condition}).
-
-Nel caso non sia stata specificata un'azione, viene utilizzata l'azione
-standard che (come vedremo in sez.~\ref{sec:sig_standard}) è propria di ciascun
-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 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.
+\func{signal} e \func{sigaction}, che tratteremo rispettivamente in
+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 alla
+radice possibili \itindex{race~condition} \textit{race condition}.
+
+Nel caso non sia stata specificata un'azione, viene utilizzata la cosiddetta
+azione predefinita che, come vedremo in sez.~\ref{sec:sig_standard}, è propria
+di ciascun segnale. Nella maggior parte dei casi questa azione comporta la
+terminazione immediata del processo, ma per alcuni segnali che rappresentano
+eventi innocui l'azione predefinita è di essere ignorati.
+
+Quando un segnale termina un processo il padre può determinare la causa della
+terminazione esaminandone lo stato di uscita così come viene riportato dalle
+funzioni \func{wait} e \func{waitpid} (vedi sez.~\ref{sec:proc_wait}). Questo
+ad esempio è il modo in cui la shell determina i motivi della terminazione di
+un programma e scrive un eventuale messaggio di errore.
I segnali che rappresentano errori del programma (divisione per zero o
-violazioni di accesso) hanno anche la caratteristica di scrivere un file di
-\itindex{core~dump} \textit{core dump} che registra lo stato del processo (ed
-in particolare della memoria e dello \itindex{stack} \textit{stack}) prima
-della terminazione. Questo può essere esaminato in seguito con un debugger
-per investigare sulla causa dell'errore. Lo stesso avviene se i suddetti
-segnali vengono generati con una \func{kill}.
+violazioni di accesso) hanno come ulteriore caratteristica della loro azione
+di default quella di scrivere un file chiamato \itindex{core~dump}
+\textit{core dump}. Si tratta di un file binario che registra lo stato del
+processo, ed in particolare della memoria e dello \itindex{stack}
+\textit{stack}, prima della terminazione. Questo file può essere esaminato in
+un secondo tempo con un apposito programma (un \textit{debugger} come
+\cmd{gdb}) per investigare sulla causa dell'errore. Lo stesso avviene se i
+suddetti segnali vengono generati con la funzione \func{kill}.
\section{La classificazione dei segnali}
\label{sec:sig_classification}
Esamineremo in questa sezione quali sono i vari segnali definiti nel sistema,
-le loro caratteristiche e tipologia, le varie macro e costanti che permettono
-di identificarli, e le funzioni che ne stampano la descrizione.
+quali sono le loro caratteristiche e la loro tipologia, tratteremo le varie
+macro e costanti che permettono di identificarli, e illustreremo le funzioni
+che ne stampano la descrizione.
\subsection{I segnali standard}
\label{sec:sig_standard}
-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 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
-nomi, che sono standardizzati e sostanzialmente uniformi rispetto alle varie
-implementazioni, che si devono usare nei programmi. Tutti i nomi e le funzioni
-che concernono i segnali sono definiti nell'header di sistema \file{signal.h}.
+Ciascun segnale è identificato dal kernel con un numero, ma benché per alcuni
+segnali questi numeri siano sempre gli stessi, tanto da essere usati come
+sinomini, l'uso diretto degli identificativi numerici da parte dei programmi è
+comunque da evitare, in quanto essi non sono mai stati standardizzati e
+possono variare a seconda dell'implementazione del sistema, e nel caso di
+Linux anche a seconda della architettura hardware e della versione del kernel.
-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 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.
+Quelli che invece sono stati, almeno a grandi linee, standardizzati, sono i
+nomi dei segnali e le costanti di preprocessore che li identificano, che sono
+tutte nella forma \texttt{SIGnome}, e sono queste che devono essere usate nei
+programmi. Come tutti gli altri nomi e le funzioni che concernono i segnali,
+esse sono definite nell'header di sistema \headfile{signal.h}.
-\begin{table}[htb]
+\begin{table}[!htb]
\footnotesize
\centering
- \begin{tabular}[c]{|c|p{8cm}|}
+ \begin{tabular}[c]{|l|c|c|l|}
\hline
- \textbf{Sigla} & \textbf{Significato} \\
+ \textbf{Segnale} &\textbf{Standard}&\textbf{Azione}&\textbf{Descrizione} \\
\hline
\hline
- A & L'azione predefinita è terminare il processo.\\
- B & L'azione predefinita è ignorare il segnale.\\
- C & L'azione predefinita è terminare il processo e scrivere un
- \itindex{core~dump} \textit{core dump}.\\
- D & L'azione predefinita è fermare il processo.\\
- E & Il segnale non può essere intercettato.\\
- F & Il segnale non può essere ignorato.\\
+ \signal{SIGHUP} &P & A & Hangup o terminazione del processo di
+ controllo. \\
+ \signal{SIGINT} &PA& A & Interrupt da tastiera (\cmd{C-c}). \\
+ \signal{SIGQUIT} &P & C & Quit da tastiera (\cmd{C-y}). \\
+ \signal{SIGILL} &PA & C & Istruzione illecita. \\
+ \signal{SIGTRAP} &S & C & Trappole per un Trace/breakpoint. \\
+ \signal{SIGABRT} &PA & C & Segnale di abort da \func{abort}. \\
+ \signal{SIGIOT} &B & C & Trappola di I/O. Sinonimo di \signal{SIGABRT}.\\
+ \signal{SIGBUS} &S & C & Errore sul bus (bad memory access). \\
+ \signal{SIGFPE} &P & C & Errore aritmetico. \\
+ \signal{SIGKILL} &P &AEF& Segnale di terminazione forzata. \\
+ \signal{SIGUSR1} &P & A & Segnale utente numero 1. \\
+ \signal{SIGSEGV} &P & C & Errore di accesso in memoria. \\
+ \signal{SIGUSR2} &P & A & Segnale utente numero 2. \\
+ \signal{SIGPIPE} &P & A & Pipe spezzata. \\
+ \signal{SIGALRM} &P & A & Segnale del timer da \func{alarm}. \\
+ \signal{SIGTERM} &P & A & Segnale di terminazione \texttt{C-\bslash}. \\
+ \signal{SIGSTKFLT}& & A & Errore sullo stack del coprocessore. \\
+ \signal{SIGCHLD} &P & B & Figlio terminato o fermato. \\
+ \signal{SIGCONT} &P & & Continua se fermato. \\
+ \signal{SIGSTOP} &P &DEF& Ferma il processo. \\
+ \signal{SIGTSTP} &P & D & Pressione del tasto di stop sul terminale. \\
+ \signal{SIGTTIN} &P & D & Input sul terminale per un processo
+ in background. \\
+ \signal{SIGTTOU} &P & D & Output sul terminale per un processo
+ in background. \\
+ \signal{SIGURG} &SB& B & Ricezione di una \textit{urgent condition} su
+ un socket. \\
+ \signal{SIGXCPU} &SB& C & Ecceduto il limite sul tempo di CPU. \\
+ \signal{SIGXFSZ} &SB& C & Ecceduto il limite sulla dimensione dei file.\\
+ \signal{SIGVTALRM}&SB& A & Timer di esecuzione scaduto. \\
+ \signal{SIGPROF} &S & A & Timer del profiling scaduto. \\
+ \signal{SIGWINCH} &B & B & Finestra ridimensionata (4.3 BSD, Sun). \\
+ \signal{SIGIO} &B & A & L'I/O è possibile (4.2 BSD). \\
+ \signal{SIGPOLL} &S & A & \textit{Pollable event} (Sys V);
+ Sinonimo di \signal{SIGIO}. \\
+ \signal{SIGPWR} & & A & Fallimento dell'alimentazione. \\
+ \signal{SIGSYS} &S & C & \textit{sistem call} sbagliata (SVID).\\
+ \signal{SIGUNUSED}& & A & Segnale inutilizzato (sinonimo di
+ \signal{SIGSYS}). \\
+ \hline
+ \signal{SIGCLD} & & & Sinonimo di \signal{SIGCHLD}. \\
+ \signal{SIGEMT} & & & Trappola di emulatore \\
+ \signal{SIGINFO} & & & Sinonimo di \signal{SIGPWR}. \\
+ \signal{SIGLOST} &-- & & Perso un lock sul file, sinonimo
+ di \signal{SIGIO}.\\
+
\hline
\end{tabular}
- \caption{Legenda delle azioni predefinite dei segnali riportate in
- tab.~\ref{tab:sig_signal_list}.}
- \label{tab:sig_action_leg}
+ \caption{Lista dei segnali ordinari in Linux.}
+ \label{tab:sig_signal_list}
\end{table}
-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
-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 tab.~\ref{tab:sig_standard_leg}.
-
+In tab.~\ref{tab:sig_signal_list} si è riportato l'elenco completo dei segnali
+definiti su Linux per tutte le possibili architetture. Ma si tenga presente
+che alcuni di questi (quelli nella sezione finale della tabella) non esistono
+sull'architettura PC, ma sono definiti sulle architetture \textit{alpha} o
+\textit{mips}.
+
+Dato che alcuni segnali erano previsti fin dallo standard ANSI C, e che i
+segnali sono presenti in tutti i sistemi unix-like, con differenze dovute alle
+implementazioni ed all'uso degli stessi la seconda colonna della tabella
+riporta con altrettante lettere gli standard in cui ciascun segnale è stato
+definito, da interpretare secondo la legenda di
+tab.~\ref{tab:sig_standard_leg}.
\begin{table}[htb]
\footnotesize
\textbf{Sigla} & \textbf{Standard} \\
\hline
\hline
- P & POSIX \\
- B & BSD \\
- L & Linux \\
- S & SUSv2 \\
+ P & POSIX.1-1990\\
+ B & BSD (4.2 BSD e Sun)\\
+ A & ANSI C\\
+ S & SUSv2 (e POSIX.1-2001)\\
+ V & System V\\
\hline
\end{tabular}
- \caption{Legenda dei valori della colonna \textbf{Standard} di
- tab.~\ref{tab:sig_signal_list}.}
+ \caption{Legenda dei valori degli standard riportati nella seconda colonna
+ di tab.~\ref{tab:sig_signal_list}.}
\label{tab:sig_standard_leg}
\end{table}
+
+Come accennato in sez.~\ref{sec:sig_notification} a ciascun segnale è
+associata una specifica azione predefinita che viene eseguita quando nessun
+gestore è installato. Anche queste sono riportate in
+tab.~\ref{tab:sig_signal_list} nella terza colonna, di nuovo identificate con
+delle lettere, la cui legenda completa è illustrate in
+tab.~\ref{tab:sig_action_leg}). Nella stessa colonna si sono indicate anche,
+le condizioni specifiche dei segnali che non possono essere intercettati o
+ignorati.
+
+Si noti come \const{SIGCONT} sia l'unico segnale a non avere una
+azione predefinita, in quanto il suo unico effetto è quello di far ripartire
+un programma fermato da un segnale di stop.
+
In alcuni casi alla terminazione del processo è associata la creazione di un
file (posto nella directory corrente del processo e chiamato \file{core}) su
cui viene salvata un'immagine della memoria del processo (il cosiddetto
per esaminare lo stato dello \itindex{stack} \textit{stack} e delle variabili
al momento della ricezione del segnale.
+
\begin{table}[htb]
\footnotesize
\centering
- \begin{tabular}[c]{|l|c|c|p{8cm}|}
+ \begin{tabular}[c]{|c|l|}
\hline
- \textbf{Segnale} &\textbf{Standard}&\textbf{Azione}&\textbf{Descrizione} \\
+ \textbf{Sigla} & \textbf{Significato} \\
\hline
\hline
- \signal{SIGHUP} &PL & A & Hangup o terminazione del processo di
- controllo. \\
- \signal{SIGINT} &PL & A & Interrupt da tastiera (\cmd{C-c}). \\
- \signal{SIGQUIT} &PL & C & Quit da tastiera (\cmd{C-y}). \\
- \signal{SIGILL} &PL & C & Istruzione illecita. \\
- \signal{SIGABRT} &PL & C & Segnale di abort da \func{abort}. \\
- \signal{SIGFPE} &PL & C & Errore aritmetico. \\
- \signal{SIGKILL} &PL &AEF& Segnale di terminazione forzata. \\
- \signal{SIGSEGV} &PL & C & Errore di accesso in memoria. \\
- \signal{SIGPIPE} &PL & A & Pipe spezzata. \\
- \signal{SIGALRM} &PL & A & Segnale del timer da \func{alarm}. \\
- \signal{SIGTERM} &PL & A & Segnale di terminazione \texttt{C-\bslash}. \\
- \signal{SIGUSR1} &PL & A & Segnale utente numero 1. \\
- \signal{SIGUSR2} &PL & A & Segnale utente numero 2. \\
- \signal{SIGCHLD} &PL & B & Figlio terminato o fermato. \\
- \signal{SIGCONT} &PL & & Continua se fermato. \\
- \signal{SIGSTOP} &PL &DEF& Ferma il processo. \\
- \signal{SIGTSTP} &PL & D & Pressione del tasto di stop sul terminale. \\
- \signal{SIGTTIN} &PL & D & Input sul terminale per un processo
- in background. \\
- \signal{SIGTTOU} &PL & D & Output sul terminale per un processo
- in background. \\
- \signal{SIGBUS} &SL & C & Errore sul bus (bad memory access). \\
- \signal{SIGPOLL} &SL & A & \textit{Pollable event} (Sys V);
- Sinonimo di \signal{SIGIO}. \\
- \signal{SIGPROF} &SL & A & Timer del profiling scaduto. \\
- \signal{SIGSYS} &SL & C & Argomento sbagliato per una subroutine (SVID).\\
- \signal{SIGTRAP} &SL & C & Trappole per un Trace/breakpoint. \\
- \signal{SIGURG} &SLB& B & Ricezione di una \textit{urgent condition} su
- un socket. \\
- \signal{SIGVTALRM}&SLB& A & Timer di esecuzione scaduto. \\
- \signal{SIGXCPU} &SLB& C & Ecceduto il limite sul tempo di CPU. \\
- \signal{SIGXFSZ} &SLB& C & Ecceduto il limite sulla dimensione dei file.\\
- \signal{SIGIOT} &L & C & IOT trap. Sinonimo di \signal{SIGABRT}. \\
- \signal{SIGEMT} &L & & \\
-% TODO che roba e` SIGEMT
- \signal{SIGSTKFLT}&L & A & Errore sullo stack del coprocessore. \\
- \signal{SIGIO} &LB & A & L'I/O è possibile (4.2 BSD). \\
- \signal{SIGCLD} &L & & Sinonimo di \signal{SIGCHLD}. \\
- \signal{SIGPWR} &L & A & Fallimento dell'alimentazione. \\
- \signal{SIGINFO} &L & & Sinonimo di \signal{SIGPWR}. \\
- \signal{SIGLOST} &L & A & Perso un lock sul file (per NFS). \\
- \signal{SIGWINCH} &LB & B & Finestra ridimensionata (4.3 BSD, Sun). \\
- \signal{SIGUNUSED}&L & A & Segnale inutilizzato (diventerà
- \signal{SIGSYS}). \\
+ A & L'azione predefinita è terminare il processo.\\
+ B & L'azione predefinita è ignorare il segnale.\\
+ C & L'azione predefinita è terminare il processo e scrivere un
+ \itindex{core~dump} \textit{core dump}.\\
+ D & L'azione predefinita è fermare il processo.\\
+ E & Il segnale non può essere intercettato.\\
+ F & Il segnale non può essere ignorato.\\
\hline
\end{tabular}
- \caption{Lista dei segnali in Linux.}
- \label{tab:sig_signal_list}
+ \caption{Legenda delle azioni predefinite dei segnali riportate nella terza
+ colonna di tab.~\ref{tab:sig_signal_list}.}
+ \label{tab:sig_action_leg}
\end{table}
+
+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.
+
La descrizione dettagliata del significato dei vari segnali, raggruppati per
tipologia, verrà affrontata nei paragrafi successivi.
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
+% molte diverse eccezioni che \signal{SIGFPE} non distingue, mentre lo
% standard IEEE per le operazioni in virgola mobile definisce varie eccezioni
% aritmetiche e richiede che esse siano notificate.
% TODO trovare altre info su SIGFPE e trattare la notifica delle eccezioni
Una modalità alternativa per utilizzare le descrizioni restituite da
\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:
+\var{sys\_siglist}, che è definita in \headfile{signal.h} e può essere
+acceduta con la dichiarazione:
\includecodesnip{listati/siglist.c}
L'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
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
+ posto di \headfile{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
\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
+chiamando \funcm{sysv\_signal}, una volta che si sia definita la macro
\macro{\_XOPEN\_SOURCE}. In generale, per evitare questi problemi, l'uso di
\func{signal}, che tra l'altro ha un comportamento indefinito in caso di
processo \itindex{thread} multi-\textit{thread}, è da evitare; tutti i nuovi
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
+Si tenga conto però che il sistema ricicla i \ids{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.
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- $>0$ & Il segnale è mandato al processo con il \acr{pid} indicato.\\
+ $>0$ & Il segnale è mandato al processo con il \ids{PID} indicato.\\
0 & Il segnale è mandato ad ogni processo del \itindex{process~group}
\textit{process group} del chiamante.\\
$-1$ & Il segnale è mandato ad ogni processo (eccetto \cmd{init}).\\
\end{table}
Solo l'amministratore può inviare un segnale ad un processo qualunque, in
-tutti gli altri casi l'\acr{uid} reale o l'\acr{uid} effettivo del processo
-chiamante devono corrispondere all'\acr{uid} reale o all'\acr{uid} salvato
+tutti gli altri casi l'\ids{UID} reale o l'\ids{UID} effettivo del processo
+chiamante devono corrispondere all'\ids{UID} reale o all'\ids{UID} salvato
della destinazione. Fa eccezione il caso in cui il segnale inviato sia
\signal{SIGCONT}, nel quale occorre che entrambi i processi appartengano alla
stessa sessione. Inoltre, dato il ruolo fondamentale che riveste nel sistema
caratteristiche dei timer, ed in effetti la stessa \func{alarm}, benché
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
+\cite{GlibcMan} che ne riporta la definizione mostrata in
fig.~\ref{fig:sig_alarm_def}.\footnote{questo comporta anche che non è il caso
di mescolare chiamate ad \func{abort} e a \func{setitimer}.}
valore della costante \texttt{HZ}, di cui abbiamo già parlato in
sez.~\ref{sec:proc_hierarchy}.} in quanto le temporizzazioni erano calcolate
in numero di interruzioni del timer (i cosiddetti \itindex{jiffies}
-''\textit{jiffies}''), ed era assicurato soltanto che il segnale non sarebbe
+``\textit{jiffies}''), ed era assicurato soltanto che il segnale non sarebbe
stato mai generato prima della scadenza programmata (l'arrotondamento cioè era
effettuato per eccesso).\footnote{questo in realtà non è del tutto vero a
causa di un bug, presente fino al kernel 2.6.12, che in certe circostanze
messaggi POSIX (vedi
sez.~\ref{sec:ipc_posix_mq}).\footnotemark\\
\const{SI\_ASYNCIO}& una operazione di I/O asincrono (vedi
- sez.~\ref{sec:file_asyncronous_access}) è stata
+ sez.~\ref{sec:file_asyncronous_io}) è stata
completata.\\
\const{SI\_SIGIO} & segnale di \signal{SIGIO} da una coda (vedi
sez.~\ref{sec:file_asyncronous_operation}).\\
\func{getsockname}, \func{getsockopt}, \func{getuid}, \func{kill},
\func{link}, \func{listen}, \func{lseek}, \func{lstat}, \func{mkdir},
\func{mkfifo}, \func{open}, \func{pathconf}, \func{pause}, \func{pipe},
- \func{poll}, \func{posix\_trace\_event}, \func{pselect}, \func{raise},
+ \func{poll}, \funcm{posix\_trace\_event}, \func{pselect}, \func{raise},
\func{read}, \func{readlink}, \func{recv}, \func{recvfrom},
\func{recvmsg}, \func{rename}, \func{rmdir}, \func{select},
\func{sem\_post}, \func{send}, \func{sendmsg}, \func{sendto},
\func{setuid}, \func{shutdown}, \func{sigaction}, \func{sigaddset},
\func{sigdelset}, \func{sigemptyset}, \func{sigfillset},
\func{sigismember}, \func{signal}, \func{sigpause}, \func{sigpending},
- \func{sigprocmask}, \func{sigqueue}, \func{sigset}, \func{sigsuspend},
+ \func{sigprocmask}, \func{sigqueue}, \funcm{sigset}, \func{sigsuspend},
\func{sleep}, \func{socket}, \func{socketpair}, \func{stat},
\func{symlink}, \func{sysconf}, \func{tcdrain}, \func{tcflow},
\func{tcflush}, \func{tcgetattr}, \func{tcgetgrp}, \func{tcsendbreak},
In particolare i campi utilizzati dai segnali \textit{real-time} sono
\var{si\_pid} e \var{si\_uid} in cui vengono memorizzati rispettivamente il
-\acr{pid} e l'\acr{uid} effettivo del processo che ha inviato il segnale, mentre
+\ids{PID} e l'\ids{UID} effettivo del processo che ha inviato il segnale, mentre
per la restituzione dei dati viene usato il campo \var{si\_value}.
\begin{figure}[!htb]
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 \textit{real-time} e da
-vari meccanismi di notifica\footnote{un campo di tipo \struct{sigval\_t} è
+vari meccanismi di notifica\footnote{un campo di tipo \type{sigval\_t} è
presente anche nella struttura \struct{sigevent} (definita in
fig.~\ref{fig:struct_sigevent}) che viene usata dai meccanismi di notifica
come quelli per i timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}), l'I/O
dal timer di sistema che governa lo \textit{scheduler},\footnote{e quindi
limitate dalla frequenza dello stesso che si ricordi, come già illustrato in
sez.~\ref{sec:proc_hierarchy}, è data dal valore della costante
- \texttt{HZ}.} i contatori usati per il calcolo dei tempo infatti erano
+ \texttt{HZ}.} i contatori usati per il calcolo dei tempi infatti erano
basati sul numero di \itindex{jiffies} \textit{jiffies} che vengono
incrementati ad ogni \textit{clock tick} del timer di sistema.\footnote{il che
comportava anche, come accennato in sez.~\ref{sec:sig_alarm_abort} per
Per usare queste funzionalità ed ottenere risoluzioni temporali più accurate,
occorre però un opportuno supporto da parte del kernel, ed i cosiddetti
-\textit{high resolution timer} che consentono di fare ciò sono stati
-introdotti nel kernel ufficiale solo a partire dalla versione
-2.6.21.\footnote{deve essere stata abilitata l'opzione di compilazione
- \texttt{CONFIG\_HIGH\_RES\_TIMERS}, erano però disponibili anche in
- precedenza come patch facenti parte dello sviluppo delle estensioni
+\itindex{high~resolution~timer} \textit{high resolution timer} che consentono
+di fare ciò sono stati introdotti nel kernel ufficiale solo a partire dalla
+versione 2.6.21.\footnote{deve essere stata abilitata l'opzione di
+ compilazione \texttt{CONFIG\_HIGH\_RES\_TIMERS}, erano però disponibili
+ anche in precedenza come patch facenti parte dello sviluppo delle estensioni
\textit{real-time} del kernel, per cui alcune distribuzioni possono avere
questo supporto anche con versioni precedenti del kernel.} Le funzioni
definite dallo standard POSIX per gestire orologi ad alta definizione però
Per poter utilizzare queste funzionalità le \acr{glibc} richiedono che la
macro \macro{\_POSIX\_C\_SOURCE} sia definita ad un valore maggiore o uguale
di \texttt{199309L} (vedi sez.~\ref{sec:intro_gcc_glibc_std}), inoltre i
-programmi che le usano devono essere collegati con la libreria delle estensioni
-\textit{real-time} usando esplicitamente l'opzione \texttt{-lrt}. Si tenga
-presente inoltre che la disponibilità di queste funzionalità avanzate può
-essere controllato dalla definizione della macro \macro{\_POSIX\_TIMERS} ad un
-valore maggiore di 0, e che le ulteriori macro
+programmi che le usano devono essere collegati con la libreria delle
+estensioni \textit{real-time} usando esplicitamente l'opzione
+\texttt{-lrt}. Si tenga presente inoltre che la disponibilità di queste
+funzionalità avanzate può essere controllato dalla definizione della macro
+\macro{\_POSIX\_TIMERS} ad un valore maggiore di 0, e che le ulteriori macro
\macro{\_POSIX\_MONOTONIC\_CLOCK}, \macro{\_POSIX\_CPUTIME} e
\macro{\_POSIX\_THREAD\_CPUTIME} indicano la presenza dei rispettivi orologi
di tipo \const{CLOCK\_MONOTONIC}, \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
\const{CLOCK\_PROCESS\_CPUTIME\_ID}.\footnote{tutte queste macro sono definite
- in \texttt{unistd.h}, che pertanto deve essere incluso per poterle
+ in \headfile{unistd.h}, che pertanto deve essere incluso per poterle
controllarle.} Infine se il kernel ha il supporto per gli \textit{high
resolution timer} un elenco degli orologi e dei timer può essere ottenuto
tramite il file \procfile{/proc/timer\_list}.
}
\end{functions}
-
% TODO, dal 2.6.39 aggiunta clock_adjtime
+% TODO manca clock_nanosleep
Con l'introduzione degli orologi ad alta risoluzione è divenuto possibile
ottenere anche una gestione più avanzata degli allarmi; abbiamo già visto in
\label{fig:struct_sigevent}
\end{figure}
-La struttura \struct{sigevent} (accessibile includendo \texttt{time.h}) è
+La struttura \struct{sigevent} (accessibile includendo \headfile{time.h}) è
riportata in fig.~\ref{fig:struct_sigevent};\footnote{la definizione effettiva
dipende dall'implementazione, quella mostrata è la versione descritta nella
- pagina di manuale di \func{timer\_create}.} il campo \var{sigev\_notify} è il
-più importante essendo quello che indica le modalità della notifica, gli altri
-dipendono dal valore che si è specificato per \var{sigev\_notify}, si sono
-riportati in tab.~\ref{tab:sigevent_sigev_notify}. La scelta del meccanismo di
-notifica viene fatta impostando uno dei valori di
+ pagina di manuale di \func{timer\_create}.} il campo \var{sigev\_notify} è
+il più importante essendo quello che indica le modalità della notifica, gli
+altri dipendono dal valore che si è specificato per \var{sigev\_notify}, si
+sono riportati in tab.~\ref{tab:sigevent_sigev_notify}. La scelta del
+meccanismo di notifica viene fatta impostando uno dei valori di
tab.~\ref{tab:sigevent_sigev_notify} per \var{sigev\_notify}, e fornendo gli
eventuali ulteriori argomenti necessari a secondo della scelta
effettuata. Diventa così possibile indicare l'uso di un segnale o l'esecuzione
(la cui definizione è riportata fig.~\ref{fig:sys_timespec_struct}). Il campo
\var{it\_value} indica la prima scadenza dell'allarme. Di default, quando il
valore di \param{flags} è nullo, questo valore viene considerato come un
-intervallo relativo al tempo corrente,\footnote{il primo allarme scatterà cioè
- dopo il numero di secondi e nanosecondi indicati da questo campo.} se invece
-si usa per \param{flags} il valore \const{TIMER\_ABSTIME},\footnote{al momento
- questo è l'unico valore valido per \param{flags}.} \var{it\_value} viene
-considerato come un valore assoluto rispetto al valore usato dall'orologio a
-cui è associato il timer.\footnote{quindi a seconda dei casi lo si potrà
- indicare o come un tempo assoluto, quando si opera rispetto all'orologio di
- sistema (nel qual caso il valore deve essere in secondi e nanosecondi dalla
- \textit{epoch}) o come numero di secondi o nanosecondi rispetto alla
- partenza di un orologio di CPU, quando si opera su uno di questi.} Infine
-un valore nullo di \var{it\_value}\footnote{per nullo si intende con valori
- nulli per entrambi i i campi \var{tv\_sec} e \var{tv\_nsec}.} può essere
-utilizzato, indipendentemente dal tipo di orologio utilizzato, per disarmare
-l'allarme.
+intervallo relativo al tempo corrente, il primo allarme scatterà cioè dopo il
+numero di secondi e nanosecondi indicati da questo campo. Se invece si usa
+per \param{flags} il valore \const{TIMER\_ABSTIME}, che al momento è l'unico
+valore valido per \param{flags}, allora \var{it\_value} viene considerato come
+un valore assoluto rispetto al valore usato dall'orologio a cui è associato il
+timer.\footnote{quindi a seconda dei casi lo si potrà indicare o come un tempo
+ assoluto, quando si opera rispetto all'orologio di sistema (nel qual caso il
+ valore deve essere in secondi e nanosecondi dalla \textit{epoch}) o come
+ numero di secondi o nanosecondi rispetto alla partenza di un orologio di
+ CPU, quando si opera su uno di questi.} Infine un valore nullo di
+\var{it\_value}, dover per nullo si intende con valori nulli per entrambi i
+campi \var{tv\_sec} e \var{tv\_nsec}, può essere utilizzato, indipendentemente
+dal tipo di orologio utilizzato, per disarmare l'allarme.
Il campo \var{it\_interval} di \struct{itimerspec} viene invece utilizzato per
-impostare un allarme periodico. Se il suo valore è nullo (se cioè sono nulli
-tutti e due i valori di detta struttura \struct{timespec}) l'allarme scatterà
-una sola volta secondo quando indicato con \var{it\_value}, altrimenti il
-valore specificato verrà preso come l'estensione del periodo di ripetizione
-della generazione dell'allarme, che proseguirà indefinitamente fintanto che
-non si disarmi il timer.
+impostare un allarme periodico. Se il suo valore è nullo, se cioè sono nulli
+tutti e due i due campi \var{tv\_sec} e \var{tv\_nsec} di detta struttura
+\struct{timespec}, l'allarme scatterà una sola volta secondo quando indicato
+con \var{it\_value}, altrimenti il valore specificato nella struttura verrà
+preso come l'estensione del periodo di ripetizione della generazione
+dell'allarme, che proseguirà indefinitamente fintanto che non si disarmi il
+timer.
Se il timer era già stato armato la funzione sovrascrive la precedente
impostazione, se invece si indica come prima scadenza un tempo già passato,
\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,
+memoria con \code{malloc}; in \headfile{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 \itindex{stack}
projects / gapil.git / blobdiff