Rimessi a posto tutti i riferimenti a figure e tabelle cancellando

[gapil.git] / simpltcp.tex

diff --git a/simpltcp.tex b/simpltcp.tex
index 4c812d3945bd67e96727fa0e1a7864c2dda4fef4..8a6b2aed9a3a28077a8c3944748c741b36be9579 100644 (file)
--- a/simpltcp.tex
+++ b/simpltcp.tex
@@ -121,14 +121,15 @@ alla funzione \code{ServEcho}.
 % processo figlio, il quale si incarica di lanciare la funzione
 % \texttt{SockEcho}.
 
 % processo figlio, il quale si incarica di lanciare la funzione
 % \texttt{SockEcho}.
 

-Il codice della funzione \code{ServEcho} è invece mostrata in \nfig, la
-comunicazione viene gestita all'interno del ciclo (linee \texttt{\small
-  6--8}).  I dati inviati dal client vengono letti dal socket con una semplice
-\func{read} (che ritorna solo in presenza di dati in arrivo), la riscrittura
-viene invece gestita dalla funzione \func{SockWrite} (descritta in
-\figref{fig:sock_SockWrite_code}) che si incarica di tenere conto
-automaticamente della possibilità che non tutti i dati di cui è richiesta la
-scrittura vengano trasmessi con una singola \func{write}.
+Il codice della funzione \code{ServEcho} è invece mostrata in
+\figref{fig:TCPsimpl_server_elem_sub}, la comunicazione viene gestita
+all'interno del ciclo (linee \texttt{\small 6--8}).  I dati inviati dal client
+vengono letti dal socket con una semplice \func{read} (che ritorna solo in
+presenza di dati in arrivo), la riscrittura viene invece gestita dalla
+funzione \func{SockWrite} (descritta in \figref{fig:sock_SockWrite_code}) che
+si incarica di tenere conto automaticamente della possibilità che non tutti i
+dati di cui è richiesta la scrittura vengano trasmessi con una singola
+\func{write}.

 
 \begin{figure}[!htb]
   \footnotesize
 
 \begin{figure}[!htb]
   \footnotesize


@@ -396,11 +397,12 @@ quando affronteremo il comportamento in caso di conclusioni anomale:
 Tutto questo riguarda la connessione, c'è però da tenere conto dell'effetto
 del procedimento di chiusura del processo figlio nel server (si veda quanto
 esaminato in \secref{sec:proc_termination}). In questo caso avremo l'invio del
 Tutto questo riguarda la connessione, c'è però da tenere conto dell'effetto
 del procedimento di chiusura del processo figlio nel server (si veda quanto
 esaminato in \secref{sec:proc_termination}). In questo caso avremo l'invio del

-segnale \macro{SIGCHILD} al padre, ma dato che non si è installato un
-manipolatore e che l'azione di default per questo segnale è quella di essere
+segnale \macro{SIGCHLD} al padre, ma dato che non si è installato un
+manipolatore e che l'azione predefinita per questo segnale è quella di essere

 ignorato, non avendo predisposto la ricezione dello stato di terminazione,
 ignorato, non avendo predisposto la ricezione dello stato di terminazione,

-otterremo che il processo figlio entrerà nello stato di zombie, come risulterà
-ripetendo il comando \cmd{ps}:
+otterremo che il processo figlio entrerà nello stato di zombie (si riveda
+quanto illustrato in \secref{sec:sig_sigchld}), come risulterà ripetendo il
+comando \cmd{ps}:

 \begin{verbatim}
  2356 pts/0    S      0:00 ./echod
  2359 pts/0    Z      0:00 [echod <defunct>]
 \begin{verbatim}
  2356 pts/0    S      0:00 ./echod
  2359 pts/0    Z      0:00 [echod <defunct>]