From: Simone Piccardi Date: Mon, 30 Apr 2012 20:07:32 +0000 (+0000) Subject: Piccole correzioni ed inizio revisione segnali. X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=82438d2b3eca2b4807e7faec6699432dd76d8577;p=gapil.git Piccole correzioni ed inizio revisione segnali. --- diff --git a/img/task_struct.dia b/img/task_struct.dia index 8fcdf23..a28e49f 100644 Binary files a/img/task_struct.dia and b/img/task_struct.dia differ diff --git a/prochand.tex b/prochand.tex index 7bd2ed9..d82076e 100644 --- a/prochand.tex +++ b/prochand.tex @@ -4314,7 +4314,7 @@ aggiungendo il suffisso \code{\_r} al nome della versione normale. % LocalWords: filesystem noexec EPERM suid sgid root nosuid ENOEXEC ENOENT ELF % LocalWords: ETXTBSY EINVAL ELIBBAD BIG EFAULT EIO ENAMETOOLONG ELOOP ENOTDIR % LocalWords: ENFILE EMFILE argc execl path execv execle execlp execvp vector -% LocalWords: list environ NULL umask pending utime cutime ustime fcntl linker +% LocalWords: list environ NULL umask utime cutime ustime fcntl linker % LocalWords: opendir libc interpreter FreeBSD capabilities mandatory access % LocalWords: control MAC SELinux security modules LSM superuser uid gid saved % LocalWords: effective euid egid dell' fsuid fsgid getuid geteuid getgid SVr diff --git a/signal.tex b/signal.tex index cba15bc..6e1579b 100644 --- a/signal.tex +++ b/signal.tex @@ -69,10 +69,11 @@ dall'utente o da un altro processo) comporta l'intervento diretto da parte del 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} @@ -85,23 +86,12 @@ individuare due tipologie fondamentali di comportamento dei segnali (dette 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 @@ -114,22 +104,33 @@ verrà eseguita. \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}). @@ -157,30 +158,32 @@ per determinare quali segnali sono bloccati e quali sono pendenti. \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. @@ -205,126 +208,175 @@ Come accennato quando un segnale viene generato, se la sua azione predefinita 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 @@ -334,17 +386,32 @@ colonna standard sono stati indicati anche gli standard in cui ciascun segnale \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 @@ -352,65 +419,34 @@ 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.