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'.
+ della pressione di tasti del terminale 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.
+dall'utente) comporta l'intervento diretto da parte del kernel che causa la
+generazione un particolare tipo di segnale.
\subsection{Le modalità di funzionamento}
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}.
+stato modificato in vari modi nelle differenti implementazioni di unix. 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
-di gestione stessa in tutti i casi in cui si vuole che il signal handler
-esterno resti attivo.
+Nella semantica \textit{unreliable} (quella implementata dalle prime versioni
+di unix) 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 di gestione 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 un secondo segnale
arriva prima che il manipolatore abbia eseguito la re-installazione di se
-stesso, nel qual caso il segnale può essere perso o causare il comportamento
+stesso. In questo caso il segnale può essere perso o causare il comportamento
originale assegnato al segnale (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.
-Nel 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}.
+Questa è la ragione per cui l'implementazione dei segnali secondo questa
+semantica viene chiamata \textit{inaffidabile}, in quanto la ricezione del
+segnale e la reinstallazione del suo manipolatore non sono operazioni
+atomiche.
+
+Un'altro problema è che in questa semantica è che 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.
+
+Un caso classico, riportato da Stevens, in cui si incontra questo problema, è
+quello in cui si usa il manipolatore per settare un flag che riporta al
+processo l'occorrenza del segnale, se si considera il seguente segmento di
+codice:
+\begin{lstlisting}
+int signal_flag = 0;
+main ()
+{
+ int sig_handler(); /* handler function */
+ ...
+ signal(SIGINT, sig_handler); /* establish handler */
+ ...
+ while(signal_flag == 0) /* while flag is zero */
+ pause(); /* go to sleep */
+ ...
+}
+int sig_handler()
+{
+ signal(SIGINT, sig_handler); /* restablish handler */
+ signal_flag = 1; /* set flag */
+}
+\end{lstlisting}
+
+
+% non supporta l'ultima delle due ma vale la pena parlarne
+% dato che è stata la prima ad essere stata implementata (e se ne trovano
+% conseguenze in alcuni programmi e funzioni di libreria) ed illustra bene
+% alcune delle caratteristiche dei segnali.
+
+
+% Un'altra caratteristica della implementazione inaffidabile è che le chiamate
+% di sistema non sono fatte ripartire automaticamente quando sono interrotte da
+% un segnale, per questo un 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}).
+Nella semantica \textit{reliable} (quella utilizzata da Linux e da ogni Unix
+moderno) invece il signal handler 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 settanto un flag
+nella process table del processo.
+
+Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
+\textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
+per tutto il tempo che passa fra la generazione del segnale e la sua consegna
+esso è detto \textsl{pendente}. In genere questa procedura viene effettuata
+dal kernel quando, riprendendo l'esecuzione del processo in questione, verifica
+la presenza del flag del segnale nella process table.
+
+In questa semantica un processo può bloccare i segnali
+
+
+% Torneremo su
+% questo più avanti in \secref{sec:sig_linux_sematic}.
+
+% 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}
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
+Per questo ad ogni tipo di segnale viene associato un nome, che corrisponde,
+tramite una macro di preprocessore, al suddetto numero. 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,
-in \ntab\ si è riportato l'elenco completo dei segnali definiti in Linux
+anche al successivo del valore numerico assegnato all'ultimo segnale definito.
+In \ntab\ si è riportato l'elenco completo dei segnali definiti in Linux
(estratto dalle man page), comparati con quelli definiti in vari standard.
-
\begin{table}[htb]
\centering
\begin{tabular}[c]{|l|c|c|c||c|l|}
\caption{Lista dei segnali in Linux}
\label{tab:sig_signal_list}
\end{table}
-in \curtab\ si sono riportate anche le caratteristiche di ciascun segnale
-indicate nel campo azione con una lettera, la cui legenda è:
+in \curtab\ si sono riportate le azioni di default di ciascun segnale
+(riassunte con delle lettere, la cui legenda completa è in \ntab), quando
+nessun manipolatore è installato un segnale può essere ignorato o causare la
+terminazione del processo.
+
+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
+\textit{core dump}), che può essere usata da un debugger per esaminare lo
+stato dello stack e delle variabili al momento della ricezione del segnale.
+
\begin{table}[htb]
\centering
\begin{tabular}[c]{c p{6cm}}
\tabref{tab:sig_signal_list}. }
\label{tab:sig_action_leg}
\end{table}
-
-
-
+la descrizione dettagliata del significato dei vari segnali, raggruppati per
+tipologia, è a seguire.
\subsubsection{Segnali di errore di programma}
\label{sec:sig_prog_error}
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.
+la registrazione su disco di un file di \textit{core dump} che viene scritto
+in un file \texttt{core} nella directory corrente del processo al momento
+dell'errore, che il debugger può usare per ricostruire lo stato del programma
+al momento della terminazione.
Questi segnali sono:
-
\begin{description}
\item \texttt{SIGFPE} Riporta un errore aritmetico fatale. Benché il nome
derivi da \textit{floating point exception} si applica a tutti gli errori
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
È tipico ottenere questo segnale dereferenziando un puntatore nullo o non
inizializzato leggendo al di la della fine di un vettore.
-
\item \texttt{SIGBUS} In maniera analoga a \texttt{SIGSEGV} questo è un
segnale che viene generato di solito quando si dereferenzia un puntatore non
inzializzato, la differenza con con \texttt{SIGSEGV} è che questo indica un
accesso non valido su un indirizzo esistente (tipo fuori dallo heap o dallo
stack), mentre \texttt{SIGBUS} indica l'accesso ad un indirizzo non valido,
come nel caso di un puntatore non allineato.
-
\item \texttt{SIGABRT} Il segnale indica che il programma stesso ha rilevato
un errore che viene riportato chiamando la funzione \texttt{abort} che
genera questo segnale.
\subsection{I segnali di allarme}
\label{sec:sig_alarm}
+Questi segnali sono generati dalla scadenza di un temporizzatore. Il loro
+comportamento di default è quello di causare la terminazione del programma, ma
+con questi segnali la scelta di default è irrilevante, in quanto il loro uso
+presuppone sempre la necessità di un manipolatore. Questi segnali sono:
\begin{description}
\item \texttt{SIGALRM}
\item \texttt{SIGVTALRM}
\subsection{I segnali di I/O asincrono}
\label{sec:sig_asyncio}
+Questi segnali operano in congiunzione con le funzioni di I/O asincrono. Per
+questo occorre comunque usare \func{fcntl} per abilitare un file descriptor a
+generare questi segnali.
+
+L'azione di default è di essere ignorati. Questi segnali sono:
\begin{description}
\item \texttt{SIGIO}
\item \texttt{SIGURG}
\subsection{I segnali per il controllo di sessione}
\label{sec:sig_job_control}
-
+Questi sono i segnali usati dal controllo di sessione, il loro uso è specifico
+per questo argomento e verrà trattato quando lo affronteremo.
+Questi segnali sono:
\begin{description}
\item \texttt{SIGCHLD}
\item \texttt{SIGCONT}
\subsection{I segnali di operazioni errate}
\label{sec:sig_oper_error}
+Questi segnali sono usati per riportare al programma errori generati da
+operazioni da lui eseguite; non indicano errori del programma quanto errori
+che impediscono il completamento dell'esecuzione dovute all'interazione con il
+resto del sistema.
+
+L'azione di default di questi segnali è di terminare il processo, questi
+segnali sono:
\begin{description}
\item \texttt{SIGPIPE}
\item \texttt{SIGLOST}
\subsection{Ulteriori segnali}
\label{sec:sig_misc_sig}
+Raccogliamo qui infine usa serie di segnali che hanno scopi differenti non
+classificabili in maniera omogenea. Questi segnali sono:
\begin{description}
-\item \texttt{SIGUSR1} e \texttt{SIGUSR2}
-\item \texttt{SIGWINCH}
-\item \texttt{SIGINFO}
+\item \texttt{SIGUSR1} e \texttt{SIGUSR2} Sono due segnali a disposizione
+ dell'utente che li può usare per quello che vuole. Possono essere utili per
+ implementare una comunicazione elementare fra processi diversi, o per
+ eseguire a richiesta una operazione utlizzando un manipolatore. L'azione di
+ default è terminare il processo.
+\item \texttt{SIGWINCH} Il nome sta per \textit{window (size) change} ed è
+ generato da molti sistemi (GNU/Linux compreso) quando le dimensioni (in
+ righe e colonne) di un terminale vengono cambiate. Viene usato da alcuni
+ programmi testuali per riformattare l'uscita su schermo quando si cambia
+ dimensione a quest'ultimo. L'azione di default è di essere ignorato.
+\item \texttt{SIGINFO} Il segnale indica una richiesta di informazioni. È
+ usato con il controllo di sessione, causa la stampa di informazioni da parte
+ del processo leader del gruppo associato al terminale di controllo, gli
+ altri processi lo ignorano.
\end{description}
+
+\section{La gestione dei segnali}
+\label{sec:sig_handlers}
+
+I segnali sono il primo e più classico esempio di eventi asincroni, che
+possono accadere in un qualunque momento durante l'esecuzione di un programma.
+Non essendo sotto il controllo del programma la gestione dei segnali non potrà
+essere controllata all'interno del flusso di esecuzione di quest'ultimo, ma
+tutto quello che si potrà fare è di specificare (al kernel, che li genera)
+quale azione andrà intrapresa quando essi si verificano.
+
+In questa sezione vedremo allora come si gestiscono i segnali, esaminando le
+funzioni che si usano per effettuare la gestione dei segnali ed analizzando le
+problematiche relative alla gestione di eventi asincroni di questo tipo.
+
+
+\subsection{La semantica dei segnali in Linux}
+\label{sec:sig_linux_semantic}
+
+
+
+\subsection{La funzione \func{signal}}
+\label{sec:sig_signal}
+
+
+
projects / gapil.git / blobdiff