From: Simone Piccardi <piccardi@gnulinux.it>
Date: Mon, 25 Feb 2002 00:15:24 +0000 (+0000)
Subject: Quattro chiacchiere su fork, exec e segnali
X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=ac5b743a5b952950626aa675bf6f4f51b030d309;p=gapil.git

Quattro chiacchiere su fork, exec e segnali
---

diff --git a/prochand.tex b/prochand.tex
index 4c16fe2..c7f441d 100644
--- a/prochand.tex
+++ b/prochand.tex
@@ -591,8 +591,8 @@ comune dopo l'esecuzione di una \func{fork} 
 \item la directory di lavoro e la directory radice (vedi
   \secref{sec:file_work_dir} e \secref{sec:file_chroot}).
 \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}).
-\item la maschera dei segnali bloccati e le azioni installate  (vedi
-\secref{sec:sig_xxx}).
+\item la maschera dei segnali bloccati (vedi \secref{sec:sig_sigpending}) e le
+  azioni installate (vedi \secref{sec:sig_gen_beha}).
 \item i segmenti di memoria condivisa agganciati al processo (vedi
 \secref{sec:ipc_xxx}). 
 \item i limiti sulle risorse (vedi \secref{sec:sys_xxx}).
@@ -608,7 +608,8 @@ le differenze fra padre e figlio dopo la \func{fork} invece sono:
   nel figlio sono posti a zero.
 \item i \textit{file lock} (vedi \secref{sec:file_locking}), che non
   vengono ereditati dal figlio.
-\item gli allarmi ed i segnali pendenti (vedi \secref{sec:sig_xxx}), che per il figlio vengono cancellati.
+\item gli allarmi ed i segnali pendenti (vedi \secref{sec:sig_gen_beha}), che
+  per il figlio vengono cancellati.
 \end{itemize*}
 
 
@@ -1199,7 +1200,7 @@ la lista completa 
   \secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
   \secref{sec:file_locking}).
 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
-  \secref{sec:sig_xxx}).
+  \secref{sec:sig_sigpending}).
 \item i limiti sulle risorse (vedi \secref{sec:sys_limits}).
 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
   \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx}).
@@ -1210,7 +1211,7 @@ processo chiamante mantengono lo stesso settaggio pure nel nuovo programma,
 tutti gli altri segnali vengono settati alla loro azione di default. Un caso
 speciale è il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN},
 può anche non essere resettato a \macro{SIG\_DFL} (si veda
-\secref{sec:sig_xxx}).
+\secref{sec:sig_gen_beha}).
 
 La gestione dei file aperti dipende dal valore che ha il flag di
 \textit{close-on-exec} (trattato in \secref{sec:file_fcntl}) per ciascun file
diff --git a/signal.tex b/signal.tex
index 6f45f11..38c3d58 100644
--- a/signal.tex
+++ b/signal.tex
@@ -73,7 +73,7 @@ semantiche) che vengono chiamate rispettivamente semantica \textsl{affidabile}
 \textit{unreliable}).
 
 Nella semantica \textsl{inaffidabile} (quella implementata dalle prime
-versioni di unix) la routine di gestione del segnale specificata dall'utente
+versioni di Unix) la routine di gestione del segnale specificata dall'utente
 non resta attiva una volta che è stata eseguita; è perciò compito dell'utente
 stesso ripetere l'installazione della stessa all'interno della routine di
 gestione, in tutti i casi in cui si vuole che il manipolatore esterno resti
@@ -762,18 +762,74 @@ indicizzate per numero di segnale, per cui una chiamata del tipo di \code{char
 
 
 
-\section{Le funzioni di base dei segnali}
-\label{sec:sig_base_func}
+\section{La gestione dei segnali}
+\label{sec:sig_management}
+
+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.
+
+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.
+
+
+\subsection{Il comportamento generale del sistema.}
+\label{sec:sig_gen_beha}
+
+Abbiamo già trattato in \secref{sec:sig_intro} le modalità con cui il sistema
+gestisce l'interazione fra segnali e processi, ci resta da esaminare però il
+comportamento delle system call; in particolare due di esse, \func{fork} ed
+\func{exec}, dovranno essere prese esplicitamente in considerazione, data la
+loro stretta relazione con la creazione di nuovi processi.
+
+Come accennato in \secref{sec:proc_fork} quando viene creato un nuovo processo
+con \func{fork} esso eredita dal padre sia le azioni che sono state settate
+per i singoli segnali, che la maschera dei segnali bloccati (tratteremo
+quest'ultimo argomento in \ref{sec:sig_sigpending}). Invece tutti i segnali
+pendenti e gli allarmi vengono cancellati; essi infatti devono essere
+recapitati solo al padre, al figlio dovranno arrivare solo i segnali dovuti
+alle sue azioni.
+
+Quando si mette in esecuzione un nuovo programma con \func{exec} (si ricordi
+quanto detto in \secref{sec:prog_exec}) tutti i segnali per i quali è stato
+installato un manipolatore vengono resettati a \macro{SIG\_DFL}. Non ha più
+senso infatti fare riferimento a funzioni definite nel programma originario,
+che non sono nemmeno presenti nello spazio di indirizzi del nuovo programma.
+
+Si noti che questo vale solo per le azioni per le quali è stato installato un
+manipolatore; viene mantenuto invece ogni eventuale settaggio dell'azione a
+\macro{SIG\_IGN}. Questo permette ad esempio alla shell di settare ad
+\macro{SIG\_IGN} le risposte per \macro{SIGINT} e \macro{SIGQUIT} per i
+programmi eseguiti in background, che altrimenti sarebbero interrotti da una
+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,
+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 quest'ultimo caso si pone il problema di cosa fare una volta che il
+manipolatori ritorni. La scelta 
 
-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 funzione \func{signal}}
 \label{sec:sig_signal}
 
-L'interfaccia più semplice alla manipolazione dei segnali è costituita dalla
+L'interfaccia più semplice per la gestione dei segnali è costituita dalla
 funzione \func{signal} che è definita fin dallo standard ANSI C.  Quest'ultimo
 però non considera sistemi multitasking, per cui la definizione è tanto vaga
 da essere del tutto inutile in un sistema Unix; è questo il motivo per cui
@@ -824,7 +880,9 @@ installare l'azione di di default\footnote{si ricordi per
 
 
 
-\subsection{La funzione \func{sigpending}}
+
+
+\subsection{Le funzioni \func{sigprocmask} e \func{sigpending}}
 \label{sec:sig_sigpending}
 
 
@@ -839,17 +897,6 @@ installare l'azione di di default\footnote{si ricordi per
 
 
 
-\section{La programmazione con i segnali}
-\label{sec:sig_use}
-
-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,
-per cui tutto quello che si può fare è di specificare (al kernel, installando
-un manipolatore) quale azione andrà intrapresa quando essi si verificano.
-
-
 \subsection{Funzioni rientranti e default dei segnali}
 \label{sec:sig_reentrant}