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 \headfile{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]
+
+\begin{table}[htb]
\footnotesize
\centering
- \begin{tabular}[c]{|l|c|c|l|}
+ \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.
projects / gapil.git / commitdiff