chiamata) può diventare sincrono o asincrono a seconda che sia generato
internamente o esternamente al processo.
-\section{La notifica dei segnali}
+\subsection{La notifica dei segnali}
\label{sec:sig_notification}
Quando un segnale viene generato il kernel prende nota del fatto; si dice così
-\subsection{I segnali standard}
+\section{I segnali standard}
\label{sec:sig_standard}
Esaminiamo ora i vari segnali disponibili e le loro caratteristiche.
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]
\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 anche le caratteristiche di ciascun segnale,
+indicate con una lettera nel campo azione, la cui legenda è:
\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; una descrizione dettagliata del significato delle
+varie azioni si trova invece in \secred{sec:sig_handlers}.
\subsubsection{Segnali di errore di programma}
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{list}
+\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
aritmetici compresa la divisione per zero e l'overflow.
% 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 o inesistente, in generale del codice illegale. Poiché il
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.
\item \texttt{SIGSYS} Sta ad indicare che si è eseguta una istruzione che
richiede l'esecuzione di una system call, ma si è fornito un codice
sbagliato per quest'ultima.
-\end{list}
+\end{description}
\subsection{I segnali di terminazione}
\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
+nessun default ha una utlità avrebbe una utilità particolare, in quanto l'uso
+di questi segnali presuppone quasi 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}
\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, partendo dalla
+descrizione di cosa fanno le azioni di default citate in precedenza, per poi
+esaminare le funzioni usate per personalizzare la gestione dei segnali,
+analizzando tutte le problematiche relative alla gestione di eventi asincroni
+di questo tipo.
+
+
+
+\subsection{Le azioni di default}
+\label{sec:sig_default_acttion}
+
projects / gapil.git / blobdiff