Correzioni varie in aereo

[gapil.git] / tcpsock.tex

diff --git a/tcpsock.tex b/tcpsock.tex
index 19a9898e0a4a948c3fa70bcb291e1c4ac160fcbf..613aea4de6e9afa31dfdbee8925dc179d4b01bc8 100644 (file)
--- a/tcpsock.tex
+++ b/tcpsock.tex
@@ -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
 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
 sez.~\ref{sec:ipc_pipes}).
 
 Per questo motivo, seguendo l'esempio di R. W. Stevens in \cite{UNP1}, si sono


@@ -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
 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
 
 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,
 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) è
 
 Le condizioni che fanno si che la funzione \func{select} ritorni segnalando
 che un socket (che sarà riportato nel primo insieme di file descriptor) è