X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=tcpsock.tex;h=5d0a01b23f05eb8c3a9319c4d43dfce1fd33cd4f;hp=19a9898e0a4a948c3fa70bcb291e1c4ac160fcbf;hb=7b43a7843d483c826a6ed13224208c615a23c4d6;hpb=18f401b26dcb222f30925a0cf03cca8db52495cb

diff --git a/tcpsock.tex b/tcpsock.tex
index 19a9898..5d0a01b 100644
--- a/tcpsock.tex
+++ b/tcpsock.tex
@@ -730,9 +730,9 @@ Si noti che si è usato \func{htonl} per assegnare il valore
 \const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è
 inutile.  Si tenga presente comunque che tutte le costanti \val{INADDR\_}
 (riportate in tab.~\ref{tab:TCP_ipv4_addr}) sono definite secondo
-\itindex{endianness} l'\textit{endianness} della macchina, ed anche se esse
-possono essere invarianti rispetto all'ordinamento dei bit, è comunque buona
-norma usare sempre la funzione \func{htonl}.
+l'\textit{endianness} della macchina, ed anche se esse possono essere
+invarianti rispetto all'ordinamento dei bit, è comunque buona norma usare
+sempre la funzione \func{htonl}.
 
 \begin{table}[htb]
   \centering
@@ -1298,7 +1298,7 @@ Quando ci si trova ad affrontare questo comportamento tutto quello che si deve
 fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di
 byte restanti, tenendo conto che le funzioni si possono bloccare se i dati non
 sono disponibili: è lo stesso comportamento che si può avere scrivendo più di
-\const{PIPE\_BUF} byte in una pipe (si riveda quanto detto in
+\const{PIPE\_BUF} byte in una \textit{pipe} (si riveda quanto detto in
 sez.~\ref{sec:ipc_pipes}).
 
 Per questo motivo, seguendo l'esempio di R. W. Stevens in \cite{UNP1}, si sono
@@ -2039,17 +2039,17 @@ esaminato in sez.~\ref{sec:proc_termination}). In questo caso avremo l'invio
 del segnale \signal{SIGCHLD} al padre, ma dato che non si è installato un
 gestore e che l'azione predefinita per questo segnale è quella di essere
 ignorato, non avendo predisposto la ricezione dello stato di terminazione,
-otterremo che il processo figlio entrerà nello stato di \itindex{zombie}
-\textit{zombie} (si riveda quanto illustrato in sez.~\ref{sec:sig_sigchld}),
-come risulterà ripetendo il comando \cmd{ps}:
+otterremo che il processo figlio entrerà nello stato di \textit{zombie} (si
+riveda quanto illustrato in sez.~\ref{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>]
 \end{verbatim}
 
-Dato che non è il caso di lasciare processi \itindex{zombie} \textit{zombie},
-occorrerà ricevere opportunamente lo stato di terminazione del processo (si
-veda sez.~\ref{sec:proc_wait}), cosa che faremo utilizzando \signal{SIGCHLD}
+Dato che non è il caso di lasciare processi \textit{zombie}, occorrerà
+ricevere opportunamente lo stato di terminazione del processo (si veda
+sez.~\ref{sec:proc_wait}), cosa che faremo utilizzando \signal{SIGCHLD}
 secondo quanto illustrato in sez.~\ref{sec:sig_sigchld}. Una prima modifica al
 nostro server è pertanto quella di inserire la gestione della terminazione dei
 processi figli attraverso l'uso di un gestore.  Per questo useremo la funzione
@@ -2070,9 +2070,9 @@ un errore di \errcode{EINTR}.
 
 Vediamo allora cosa comporta tutto questo nel nostro caso: quando si chiude il
 client, il processo figlio che gestisce la connessione terminerà, ed il padre,
-per evitare la creazione di \itindex{zombie} \textit{zombie}, riceverà il
-segnale \signal{SIGCHLD} eseguendo il relativo gestore. Al ritorno del gestore
-però l'esecuzione nel padre ripartirà subito con il ritorno della funzione
+per evitare la creazione di \textit{zombie}, riceverà il segnale
+\signal{SIGCHLD} eseguendo il relativo gestore. Al ritorno del gestore però
+l'esecuzione nel padre ripartirà subito con il ritorno della funzione
 \func{accept} (a meno di un caso fortuito in cui il segnale arriva durante
 l'esecuzione del programma in risposta ad una connessione) con un errore di
 \errcode{EINTR}. Non avendo previsto questa eventualità il programma considera
@@ -2491,12 +2491,12 @@ Per capire come questa avvenga comunque, non avendo inserito nel codice nessun
 controllo di errore, occorre ricordare che, a parte la bidirezionalità del
 flusso dei dati, dal punto di vista del funzionamento nei confronti delle
 funzioni di lettura e scrittura, i socket sono del tutto analoghi a delle
-pipe. Allora, da quanto illustrato in sez.~\ref{sec:ipc_pipes}, sappiamo che
-tutte le volte che si cerca di scrivere su una pipe il cui altro capo non è
-aperto il lettura il processo riceve un segnale di \signal{SIGPIPE}, e questo è
-esattamente quello che avviene in questo caso, e siccome non abbiamo un
-gestore per questo segnale, viene eseguita l'azione preimpostata, che è quella
-di terminare il processo.
+\textit{pipe}. Allora, da quanto illustrato in sez.~\ref{sec:ipc_pipes},
+sappiamo che tutte le volte che si cerca di scrivere su una \textit{pipe} il
+cui altro capo non è aperto il lettura il processo riceve un segnale di
+\signal{SIGPIPE}, e questo è esattamente quello che avviene in questo caso, e
+siccome non abbiamo un gestore per questo segnale, viene eseguita l'azione
+preimpostata, che è quella di terminare il processo.
 
 Per gestire in maniera più corretta questo tipo di evento dovremo allora
 modificare il nostro client perché sia in grado di trattare le varie tipologie
@@ -2772,13 +2772,14 @@ sappiamo che la funzione ritorna quando uno o più dei file descriptor messi
 sotto controllo è pronto per la relativa operazione.
 
 In quell'occasione non abbiamo però definito cosa si intende per pronto,
-infatti per dei normali file, o anche per delle pipe, la condizione di essere
-pronti per la lettura o la scrittura è ovvia; invece lo è molto meno nel caso
-dei socket, visto che possono intervenire tutte una serie di possibili
-condizioni di errore dovute alla rete. Occorre allora specificare chiaramente
-quali sono le condizioni per cui un socket risulta essere ``\textsl{pronto}''
-quando viene passato come membro di uno dei tre \itindex{file~descriptor~set}
-\textit{file descriptor set} usati da \func{select}.
+infatti per dei normali file, o anche per delle \textit{pipe}, la condizione
+di essere pronti per la lettura o la scrittura è ovvia; invece lo è molto meno
+nel caso dei socket, visto che possono intervenire tutte una serie di
+possibili condizioni di errore dovute alla rete. Occorre allora specificare
+chiaramente quali sono le condizioni per cui un socket risulta essere
+``\textsl{pronto}'' quando viene passato come membro di uno dei tre
+\itindex{file~descriptor~set} \textit{file descriptor set} usati da
+\func{select}.
 
 Le condizioni che fanno si che la funzione \func{select} ritorni segnalando
 che un socket (che sarà riportato nel primo insieme di file descriptor) è