Si noti come il figlio operi solo sul socket connesso, chiudendo
immediatamente (\texttt{\small 33}) il socket \var{list\_fd}; mentre il padre
continua ad operare solo sul socket in ascolto chiudendo (\texttt{\small 48})
-\var{sock\_fd} al ritorno dalla \func{fork}. Per quanto abbiamo detto in
+\var{conn\_fd} al ritorno dalla \func{fork}. Per quanto abbiamo detto in
\secref{sec:TCP_func_close} nessuna delle due chiamate a \func{close} causa
l'innesco della sequenza di chiusura perché il numero di riferimenti al file
descriptor non si è annullato.
Infatti subito dopo la creazione del socket \var{list\_fd} ha una referenza, e
-lo stesso vale per \var{sock\_fd} dopo il ritorno di \func{accept}, ma dopo la
+lo stesso vale per \var{conn\_fd} dopo il ritorno di \func{accept}, ma dopo la
\func{fork} i descrittori vengono duplicati nel padre e nel figlio per cui
entrambi i socket si trovano con due referenze. Questo fa si che quando il
padre chiude \var{sock\_fd} esso resta con una referenza da parte del figlio,
interrotta dall'arrivo di \const{SIGCHLD}, è quella ad \func{accept}, che è
l'unica funzione che può mettere il processo padre in stato di sleep nel
periodo in cui un figlio può terminare; si noti infatti come le altre
-\textit{slow system call}\footnote{si ricordi la distinzione fatta in
- \secref{sec:sig_gen_beha}.} o sono chiamate prima di entrare nel ciclo
-principale, quando ancora non esistono processi figli, o sono chiamate dai
-figli stessi e non risentono di \const{SIGCHLD}.
+\index{system call lente} \textit{slow system call}\footnote{si ricordi la
+ distinzione fatta in \secref{sec:sig_gen_beha}.} o sono chiamate prima di
+entrare nel ciclo principale, quando ancora non esistono processi figli, o
+sono chiamate dai figli stessi e non risentono di \const{SIGCHLD}.
Per questo l'unica modifica sostanziale nel ciclo principale (\texttt{\small
23--42}), rispetto precedente versione di \figref{fig:TCP_ServEcho_first}, è