slow system call e segnali
authorSimone Piccardi <piccardi@gnulinux.it>
Mon, 25 Feb 2002 18:45:29 +0000 (18:45 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Mon, 25 Feb 2002 18:45:29 +0000 (18:45 +0000)
signal.tex

index ce3ee76d17b9cbf588100df95000d75432b363d0..cb163ba41d78fa06e7e0e29a253dab7c55342148 100644 (file)
@@ -767,13 +767,14 @@ indicizzate per numero di segnale, per cui una chiamata del tipo di \code{char
 
 I segnali sono il primo e più classico esempio di eventi asincroni, cioè di
 eventi che possono accadere in un qualunque momento durante l'esecuzione di un
 
 I segnali sono il primo e più classico esempio di eventi asincroni, cioè di
 eventi che possono accadere in un qualunque momento durante l'esecuzione di un
-programma.  Dato che la loro gestione non è sotto il controllo del programma
-essa non può essere effettuata all'interno del normale flusso di esecuzione.
+programma. Per questa loro caratteristica la loro gestione non può essere
+effettuata all'interno del normale flusso di esecuzione dello stesso, ma è
+delegata appunto agli eventuali manipolatori che si sono installati.
 
 
-In questa sezione vedremo come si effettua gestione dei segnali, a partire dal
-comportamento del sistema, passando per le varie funzioni relative ai segnali,
-affrontando inoltre le varie promblematiche di programmazione che si devono
-tenere presenti quando si ha a che fare con essi.
+In questa sezione vedremo come si effettua gestione dei segnali, a partire
+dalla loro interazione con le system call, passando per le varie funzioni che
+permettono di installare i manipolatori e controllare le reazioni di un
+processo alla loro occorrenza.
 
 
 \subsection{Il comportamento generale del sistema.}
 
 
 \subsection{Il comportamento generale del sistema.}
@@ -808,21 +809,32 @@ successiva pressione di \texttt{C-c} o \texttt{C-y}.
 
 Per quanto riguarda tutte le altre system call esse vengono tradizionalmente
 classificate, proprio in base al loro comportamento nei confronti dei segnali,
 
 Per quanto riguarda tutte le altre system call esse vengono tradizionalmente
 classificate, proprio in base al loro comportamento nei confronti dei segnali,
-in lente (\textit{slow}) e veloci (\textit{fast}). La gran parte appartiene a
-quest'ultima categoria che non è influenzata dall'arrivo di un segnale. In tal
-caso un eventuale manipolatore viene sempre eseguito dopo che la system call è
-stata completata. Esse sono dette \textit{fast} proprio in quanto attendere la
-loro esecuzione per eseguire un manipolatore non comporta nessun
-inconveniente.
-
-Esistono però dei casi (ad esempio le funzioni di I/O che si bloccano in
-attesa di dati in ingresso) in cui tutto questo non è possibile proprio perché
-renderebbe impossibile una risposta pronta al segnale (per questo sono
-chiamate \textit{slow}), pertanto un eventuale manipolatore sarà eseguito
-prima che la system call sia ritornata.
+in \textsl{lente} (\textit{slow}) e \textsl{veloci} (\textit{fast}). La gran
+parte appartiene a quest'ultima categoria che non è influenzata dall'arrivo di
+un segnale. In tal caso un eventuale manipolatore viene sempre eseguito dopo
+che la system call è stata completata. Esse sono dette \textsl{veloci} proprio
+in quanto la loro esecuzione è sostanzialmente immediata e attendere per
+eseguire un manipolatore non comporta nessun inconveniente.
+
+Esistono però dei casi in cui questo non è possibile perché renderebbe
+impossibile una risposta pronta al segnale. In generale questo avviene tutte
+le volte che si ha a che fare con system call che possono bloccarsi
+indenfinitamente, che per questo vengono chiamate \textsl{lente}. Un elenco
+dei casi in cui si presenta questa situazione è il seguente:
+\begin{itemize*}
+\item lettura da file che possono bloccarsi in attesa di dati non ancora
+  presenti (come per certi dispositivi, la rete o le pipe).
+\item scrittura sugli stessi file, nel caso in cui dati non possano essere
+  accettati immediatamente.
+\item apertura di un file di dipositivo che richiede operazioni non immediate
+  per una una risposta. 
+\item operazioni eseguite con \func{ioctl} che non è detto possano essere
+  eseguite immediatamente.
+\end{itemize*}
 
 
-In quest'ultimo caso si pone il problema di cosa fare una volta che il
-manipolatori ritorni. La scelta 
+In questo caso si pone il problema di cosa fare una volta che il manipolatore
+sia ritornato. La scelta originaria dei primi Unix era quella di far ritornare
+la system call con un errore di \macro{EINTR}, 
 
 
 
 
 
 
@@ -880,11 +892,8 @@ installare l'azione di di default\footnote{si ricordi per
 
 
 
 
 
 
-
-
-\subsection{Le funzioni \func{sigprocmask} e \func{sigpending}}
-\label{sec:sig_sigpending}
-
+\subsection{Funzioni rientranti e default dei segnali}
+\label{sec:sig_reentrant}
 
 
 
 
 
 
@@ -895,10 +904,15 @@ installare l'azione di di default\footnote{si ricordi per
 \label{sec:sig_alarm_pause}
 
 
 \label{sec:sig_alarm_pause}
 
 
+\section{Il controllo dei segnali}
+\label{sec:sig_control}
 
 
 
 
-\subsection{Funzioni rientranti e default dei segnali}
-\label{sec:sig_reentrant}
+
+
+\subsection{Le funzioni \func{sigprocmask} e \func{sigpending}}
+\label{sec:sig_sigpending}
+
 
 
 \subsection{La funzione \func{sigaction}}
 
 
 \subsection{La funzione \func{sigaction}}
@@ -907,6 +921,11 @@ installare l'azione di di default\footnote{si ricordi per
 
 
 
 
 
 
+, affrontando inoltre le varie problematiche di programmazione che si devono
+tenere presenti quando si ha a che fare con essi.
+
+
+
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"