[gapil.git] / signal.tex

\chapter{I segnali}
\label{sec:signals}

I segnali sono il primo e più semplice meccanismo di comunicazione nei
confronti dei processi. Non portano con se nessuna informazione che non sia il
loro tipo, si tratta in sostanza di un'interruzione software portata ad un
processo.

In genere i segnali vengono usati dal kernel per riportare situazioni
eccezionali (come errori di accesso, eccezioni aritmetiche, etc.) ma possono
anche essere usati come forma elementare di comunicazione fra processi (ad
esempio vengono usati per il controllo di sessione), per notificare eventi
(come la terminazione di un processo figlio), etc.

\section{I concetti base}
\label{sec:sig_base}

Come il nome stesso indica i segnali sono usati per notificare ad un processo
l'occorrenza di un evento eccezionale. Gli eventi che possono generare un
segnale sono vari; un breve elenco di possibile cause è il seguente:

\begin{itemize}
\item un errore del programma, come una divisione per zero o un tentativo di
  accesso alla memoria fuori dai limiti validi.
\item la terminazione di un processo figlio.
\item la scadenza di un timer o di un allarme.
\item il tentativo di effettuare un'operazione di input/output che non può
  essere eseguita.
\item una richiesta dell'utente di terminare o fermare il programma. In genere
  si realizza attraverso un segnale mandato dalla shell in corrispondenza
  della pressione di tasti come 'ctrl-c' o 'ctrl-z'.
\item l'esecuzione di una \texttt{kill} o di una \texttt{raise} da parte del
  processo stesso o di un'altro (solo nel caso della \texttt{kill}).
\end{itemize}

Ciascuno di questi eventi (tranne gli ultimi due che sono controllati
dall'utente) comporta da parte del kernel la generazione un particolare tipo
di segnale.


\subsection{Le modalità di funzionamento}
\label{sec:sig_semantics}

Quando un processo riceve un segnale il kernel esegue una apposita routine di
gestione (il cosiddetto \textit{signal handler}) che può essere specificata
dall'utente.  Negli anni il comportamento del sistema in risposta ai segnali è
stato modificato in vari modi nelle differenti implementazioni di unix.
Attualmente si possono individuare due tipologie fondamentali di comportamento
dei segnali (dette semantiche) che vengono chiamate rispettivamente
\textit{reliable} e \textit{unreliable}.

Nella semantica \textit{unreliable} la routine di gestione del segnale
specificata dall'utente non resta installata una volta chiamata; è perciò a
carico dell'utente stesso ripetere l'installazione all'interno della routine
stessa in tutti i casi in cui si vuole che il signal handler esterno resti
attivo.

Per questo motivo è possibile una race-condition in cui il segnale arriva
prima che il suo manipolatore sia installato, nel qual caso il segnale può
essere perso o causare il comportamento originale (in genere la terminazione
del processo). Questa è la ragione per cui detti segnali sono chiamati
\textit{inaffidabili}, in quanto la ricezione del segnale e la reinstallazione
del suo manipolatore non sono operazioni atomiche.

In caso di implementazione inaffidabile le chiamate di sistema non sono fatte
ripartire automaticamente quando sono interrotte da un segnale, per questo il
programma deve controllare lo stato di uscita della chiamata al sistema e
riperterla nel caso l'errore riportato da \texttt{errno} sia \texttt{EINTR}.

Inoltre in questo caso non esiste una modalità semplice per ottenere una
operazione di pausa atomica (cioè mandare in sleep un processo fino all'arrivo
di un segnale), dato che ci sono casi in cui un segnale può arrivare quando il
programma non è in grado di accorgersene.

In caso di segnali \textit{reliable} invece il signal handler resta installato
quando viene chiamato e i problemi precedenti sono evitati. Inoltre alcune
chiamate di sistema possono essere fatte ripartire automaticamente e si può
ottenere un'operazione di pausa atomica (usando la funzione POSIX
\texttt{sigsuspend}).


\subsubsection{Tipi di segnali}
\label{sec:sig_types}


In generale gli eventi che generano i segnali si possono dividere in tre
categorie principali: errori, eventi 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 la condizione di errore più comune comporta la restituzione di un
codice di errore da parte di una funzione di libreria, sono gli errori che
possono avvenire ovunque in un programma che causano l'emissione di un
segnale, come le divisioni per zero o l'uso di indirizzi di memoria non validi.

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.

Una richiesta esplicita significa l'uso di una chiamata di sistema (come
\texttt{kill} o \texttt{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.

Si dice poi che i segnali possono essere \textit{asincroni} o
\textit{sincroni}. Un segnale sincrono è legato ad una azione specifica di un
programma ed è inviato (a meno che non sia bloccato) durante tale azione;
molti errori generano segnali 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.

I segnali asincroni sono generati da eventi fuori dal controllo del processo
che li riceve e arrivano in tempi impredicibili nel corso dell'esecuzione del
programma. Eventi esterni come la terminazione di un processo figlio generano
segnali asincroni, così come le richieste di generazione di un segnale
effettuate da altri processi.

In generale un tipo di segnale o è sincrono o è asincrono, salvo il caso in
cui esso sia generato attraverso una richiesta esplicita tramite chiamata al
sistema, nel qual caso qualunque tipo di segnale (quello scelto nella
chiamata) può diventare sincrono o asincrono a seconda che sia generato
internamente o esternamente al processo.

\section{La notifica dei segnali}
\label{sec:sig_notification}

Quando un segnale viene generato il kernel prende nota del fatto; si dice così
che diventa \textit{pending} (sospeso), e rimarrà tale fino al momento in cui
verrà notificato al processo a cui deve essere inviato.

Normalmente l'invio al processo che deve ricevere il segnale è immediato, a
meno che il segnale in questione non sia stato bloccato (\textit{blocked}) nel
qual caso l'invio non avviene ed il segnale resta sospeso indefinitamente. Una
volta però che esso venga sbloccato il segnale sarà subito notificato.

Una volta che il segnale viene notificato (che questo avvenga subito o dopo
una attesa più o meno lunga) viene eseguita l'azione specificata per detto
segnale. Per alcuni segnali (\texttt{SIGKILL} e \texttt{SIGSTOP}) questa azione
è fissa e non può essere cambiata, ma per tutti gli altri il programma può
specificare una scelta fra le tre seguenti:

\begin{itemize}
\item ignorare il segnale
\item utilizzare il manipolatore (\textit{signal handler}) specificato
\item accettare l'azione di default per quel segnale.
\end{itemize}

Il programma può specificare queste scelte usano le due routine
\texttt{signal} e \texttt{sigaction}; se si è installato un manipolatore sarà
quest'ultimo a intercettare il segnale ed ad essere eseguito, e mentre viene
eseguito (onde evitare race conditions) il segnale viene bloccato.

Se l'azione specificata per un certo tipo di segnale è quella di ignorarlo
questo sarà scartato immediatamente ogni volta che verrà generato, e questo
avverrà anche se in quel momento il segnale è bloccato. Per questo un segnale
ignorato non sarà mai notificato, anche se in seguito si sarà specificata una
diversa azione per lo stesso segnale.

Se arriva un segnale per il quale non è stato specificata un'azione viene
utilizzata l'azione standard. Questa è diversa da segnale a segnale (come
vedremo in \ref{sec:sig_standard}) ma per la maggior parte essa comporta la
terminazione del processo, per alcuni che invece rappresentano eventi innocui
l'azione standard è di non fare nulla.

Quando un segnale termina un processo, il padre può determinare la causa della
terminazione esaminando il codice di stato riportato delle funzioni
\texttt{wait} e \texttt{waitpid} in cui è riportato anche se la causa è un
segnale e nel caso quale; questo è 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
\textit{core dump} che registra lo stato del processo prima della terminazione
e può essere esaminato da un debugger per investigare sulla causa dell'errore.
Lo stesso avviene se i suddetti segnale vengono generati artificialmente con
una \texttt{kill}.



\subsection{I segnali standard}
\label{sec:sig_standard}

Esaminiamo ora i vari segnali disponibili e le loro caratteristiche. 
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.

Per questo ad ogni tipo di segnale viene associato un nome, che corrisponde
tramite una macro di preprocessore, al suddetto numero, e sono questi nomi,
che sono standardizzati e 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 \texttt{signal.h}.

Il numero totale di segnali presenti è dato dalla macro \texttt{NSIG}, e dato
che i numeri dei segnali sono allocati progressivamente, essa corrisponde
anche al successivo del valore numerico assegnato all'ultimo segnale definito.


\subsubsection{Segnali di errore di programma}

Questi segnali sono generati quando il sistema, o in certi casi direttamente
l'hardware (come per i page fault non valildi) rileva un qualche errore
insanabile nel programma in esecuzione. In generale la generazione di questi
segnali significa che il programma ha dei gravi problemi (ad esempio ha
dereferenziato un puntatore non valido o ha eseguito una operazione aritmetica
proibita) e l'esecuzione non può essere proseguita.

In genere si intercettano questi segnali per permettere al programma di
terminare in maniera pulita, ad esempio per ripristinare i settaggi della
console o eliminare i file di lock prima dell'uscita.  In questo caso il
manipolatore deve concludersi ripristinando l'azione di default e rialzando il
segnale, in questo modo il programma si concluderà senza effetti spiacevoli,
ma riportando lo stesso stato di uscita che avrebbe avuto se il manipolatore
non ci fosse stato.

L'azione di default per tutti questi segnali è causare la terminazione del
processo che li ha causati. In genere oltre a questo il segnale provoca pure
la registrazione su disco di un \textit{core dump file} che viene scritto in
un file \texttt{core} nella directory corrente del processo al momento
dell'errore.

Questi segnali sono:

\begin{itemize}
\item \texttt{SIGFPE} Riporta un errore aritmetico fatale. Benché il nome
  derivi da \textit{floating point exception} si applica a tutti gli errori
  aritmetici compresa la divisione per zero e l'overflow.

%   Per questo segnale le cose sono complicate dal fatto che possono esserci
%   molte diverse eccezioni che \texttt{SIGFPE} non distingue, mentre lo
%   standard IEEE per le operazioni in virgola mobile definisce vaire eccezioni
%   aritmetiche e richiede che esse siano notificate.  
\item \texttt{SIGILL} Il nome deriva da \textit{illegal instruction},
  significa che il programma sta cercando di eseguire una istruzione
  privilegiata od inesistente, in generale del codice illegale. Poiché il
  compilatore del C genera del codice valido si ottiene questo segnale se il
  file eseguibile è corrotto o si stanno cercando di eseguire dei
  dati. Quest'ultimo caso può accadere quando si passa un puntatore sbagliato
  al posto di un puntatore a funzione, o si eccede la scrittura di un array di
  una variabile locale, andando a corrompere lo stack. Lo stesso segnale viene
  generato in caso di overflow dello stack o di problemi nell'esecuzione di
  di un signal handler.

\item \texttt{SIGSEGV} Il nome deriva da \textit{segment violation}, e
  significa che il programma sta cercando di leggere o scrivere in una zona di
  memoria protetta al di fuori di quella che gli è stata riservata dal
  sistema. In genere è il meccanismo della protezione della memoria che si
  accorge dell'errore ed il kernel genera il segnale.

  È tipico ottenere questo segnale dereferenziando un puntatore nullo o non
  inizializzatoo leggendo al di la della fine di un vettore. 

\item \texttt{SIGBUS} 
\item \texttt{SIGABRT} 
\item \texttt{SIGTRAP} 
\item \texttt{SIGSYS} 

\end{itemize}