Aggiunta implementazione di Signal e riferimenti nel capitolo relativo

di simpltcp.tex

diff --git a/signal.tex b/signal.tex
index 6f6c1110e6e1be70c400a6026ada77d813345b9e..703d876a06bade859600496f050995c23e7f36ff 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -1899,7 +1899,40 @@ che in certi sistemi questi possono essere diversi. In generale dunque, a meno
 che non si sia vincolati allo standard ISO C, è sempre il caso di evitare
 l'uso di \func{signal} a favore di \func{sigaction}.
 
+Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
+che abbia le stesse caratteristiche di \func{signal} a definire una funzione
+equivalente (che si trova come \code{inline} nel file \file{wrapper.h} dei
+sorgenti allegati) \code{Signal}, riportata in \figref{fig:sig_Signal_code}.
 
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}{}
+typedef void SigFunc(int);
+inline SigFunc * Signal(int signo, SigFunc *func) 
+{
+    struct sigaction new_handl, old_handl;
+    new_handl.sa_handler=func;
+    /* clear signal mask: no signal blocked during execution of func */
+    if (sigemptyset(&new_handl.sa_mask)!=0){  /* initialize signal set */
+        perror("cannot initializes the signal set to empty"); /* see mess. */
+        exit(1);
+    }
+    new_handl.sa_flags=0;                  /* init to 0 all flags */
+    /* change action for signo signal */
+    if (sigaction(signo,&new_handl,&old_handl)){ 
+        perror("sigaction failed on signal action setting");
+        exit(1);
+    }
+    return (old_handl.sa_handler);
+}
+    \end{lstlisting}
+  \end{minipage} 
+  \normalsize 
+  \caption{Una funzione equivalente a \func{signal} definita attraverso
+    \func{sigaction}.} 
+  \label{fig:sig_Signal_code}
+\end{figure}
 
 \subsection{La gestione della \textsl{maschera dei segnali} o 
   \textit{signal mask}}

diff --git a/simpltcp.tex b/simpltcp.tex
index f210f219e3114717d0138eab1bea059b441f98ad..4da8e81d70e17c58fea92b2fc1415d02df77ab49 100644 (file)
--- a/simpltcp.tex
+++ b/simpltcp.tex
@@ -29,11 +29,11 @@ caratteri dallo standard input e la scrive sul server, il server legger
 linea dalla connessione e la riscriverà all'indietro; sarà compito del client
 leggere la risposta del server e stamparla sullo standard output.
 
-Si è scelto di usare questo servizio, seguendo lo Stevens, perché costituisce
-il prototipo ideale di una generica applicazione di rete in cui un server
-risponde alle richieste di un client; tutto quello che cambia nel caso si una
-applicazione più complessa è la elaborazione dell'input del client da parte
-del server nel fornire le risposte in uscita. 
+Si è scelto di usare questo servizio, seguendo l'esempio di \cite{UNP1},
+perché costituisce il prototipo ideale di una generica applicazione di rete in
+cui un server risponde alle richieste di un client; tutto quello che cambia
+nel caso si una applicazione più complessa è la elaborazione dell'input del
+client da parte del server nel fornire le risposte in uscita.
 
 Partiremo da un'implementazione elementare che dovrà essere rimaneggiata di
 volta in volta per poter tenere conto di tutte le evenienze che si possono
@@ -329,11 +329,11 @@ un risultato del tipo:
 tre processi, tutti in stato di \textit{sleep} (S).
 
 Se a questo punto si inizia a scrivere qualcosa sul client niente sarà
-trasmesso fin tanto che non si prema il ritorno carrello, allora la
-\func{fgets} ritornerà e a questo punto il client scriverà quanto immesso
-sul socket, poi rileggerà quanto gli viene inviato all'indietro dal server, e
-questo sarà inviato sullo standard output, che nel caso ne provoca
-l'immediatamente stampa a video.
+trasmesso fin tanto che non si prema il ritorno carrello (si ricordi quanto
+trattato in \secref{sec:file_line_io}), allora la \func{fgets} ritornerà e a
+questo punto il client scriverà quanto immesso sul socket, poi rileggerà
+quanto gli viene inviato all'indietro dal server, e questo sarà inviato sullo
+standard output, che nel caso ne provoca l'immediatamente stampa a video.
 
 
 \subsection{La conclusione normale}
@@ -407,9 +407,13 @@ ripetendo il comando \cmd{ps}:
 Poiché non è possibile lasciare processi zombie che pur inattivi occupano
 spazio nella tabella dei processi e a lungo andare saturerebbero le risorse
 del kernel, occorrerà ricevere opportunamente lo stato di terminazione del
-processo (si veda \secref{sec:proc_wait}), cosa che faremo utilizzando il
-segnale, per questo installeremo un manipolatore usando la funzione
-\func{Signal} (trattata in dettaglio in \secref{sec:sig_signal}).
+processo (si veda \secref{sec:proc_wait}), cosa che faremo utilizzando
+\macro{SIGCHLD} secondo quanto illustrato in \secref{sec:sig_sigchld}.
+
+La prima modifica al nostro server è pertanto quella di inserire la gestione
+della terminazione dei processi figli attraverso l'uso di un manipolatore.
+Per questo usiamo la funzione \code{Signal} illustrata in
+\figref{fig:sig_Signal_code}. 
 
 
 %%% Local Variables: