La gestione del servizio \textit{echo} viene effettuata interamente nella
funzione \code{ServEcho}, il cui codice è mostrato in
-\figref{fig:TCP_ServEcho}, e la comunicazione viene gestita all'interno di un
-ciclo (\texttt{\small 6--13}). I dati inviati dal client vengono letti
+\figref{fig:TCP_ServEcho_first}, e la comunicazione viene gestita all'interno
+di un ciclo (\texttt{\small 6--13}). I dati inviati dal client vengono letti
(\texttt{\small 6}) dal socket con una semplice \func{read}, di cui non si
controlla lo stato di uscita, assumendo che ritorni solo in presenza di dati
in arrivo. La riscrittura (\texttt{\small 7}) viene invece gestita dalla
\normalsize
\caption{Codice della prima versione della funzione \code{ServEcho} per la
gestione del servizio \textit{echo}.}
- \label{fig:TCP_ServEcho}
+ \label{fig:TCP_ServEcho_first}
\end{figure}
In caso di errore di scrittura (si ricordi che \func{FullWrite} restituisce un
\noindent
all'esempio illustrato in \figref{fig:TCP_echo_server_first_code}.
-In questo modo però si introduce un altro problema, si ricordi infatti che,
+In questo modo però si introduce un altro problema. Si ricordi infatti che,
come spiegato in \secref{sec:sig_gen_beha}, quando un programma si trova in
stato di \texttt{sleep} durante l'esecuzione di una system call, questa viene
interrotta alla ricezione di un segnale. Per questo motivo, alla fine
dell'esecuzione del gestore del segnale, se questo ritorna, il programma
-riprenderà l'esecuzione ritornando dalla system call con un errore di
-\errcode{EINTR}.
+riprenderà l'esecuzione ritornando dalla system call interrotta con 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,
accept error: Interrupted system call
\end{verbatim}%#
-
Come accennato in \secref{sec:sig_gen_beha} le conseguenze di questo
comportamento delle system call possono essere superate in due modi diversi,
il più semplice è quello di modificare il codice di \func{Signal} per
riavvio automatico delle system call, fornita da \const{SA\_RESTART}, è
opzionale, per cui non è detto che essa sia disponibile su qualunque sistema.
Inoltre in certi casi,\footnote{Stevens in \cite{UNP1} accenna che la maggior
- parte degli Unix derivati da BSD non fanno ripartire \func{select}, ed
- alcuni non fanno ripartire neanche \func{accept} e \func{recvfrom}; nel caso
- di Linux questa è disponibile.} anche quando questa è presente, non è detto
-possa essere usata con \func{accept}. La portabilità però viene al costo di
-una riscrittura parziale del server, secondo quanto mostrato in
+ parte degli Unix derivati da BSD non fanno ripartire \func{select}; altri
+ non riavviano neanche \func{accept} e \func{recvfrom}, cosa che invece nel
+ caso di Linux viene sempre fatta.} anche quando questa è presente, non è
+detto possa essere usata con \func{accept}. La portabilità però viene al costo
+di una riscrittura parziale del server, secondo quanto mostrato in
\figref{fig:TCP_echo_server_code}, dove si è riportata la sezione di codice
-modificata per la seconda versione del programma.
+modificata per la seconda versione del programma, che si trova nel file
+\file{}.
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15.6cm}
- \includecodesample{listati/TCP_echod.c}
+ \includecodesample{listati/TCP_echod_second.c}
\end{minipage}
\normalsize
\caption{La sezione nel codice della seconda versione del server
system call} o sono chiamate prima di entrare nel ciclo principale, quando
ancora non esistono processi figli, o sono chiamate dai figli stessi.} Per
questo l'unica modifica sostanziale nella nuova versione del server, rispetto
-alla versione precedente vista in \figref{fig:TCP_ServEcho}, è nella sezione
-(\texttt{\small 9--14}) in cui si effettua la chiamata di \func{accept}.
-Quest'ultima viene effettuata (\texttt{\small 9--10}) all'interno di un ciclo
-di \code{while}\footnote{la sintassi del C relativa a questo ciclo può non
- essere del tutto chiara. In questo caso infatti si è usato un ciclo vuoto
- che non esegue nessuna istruzione, in questo modo quello che viene ripetuto
- con il ciclo è soltanto il codice che esprime la condizione all'interno del
- \code{while}.} che la ripete indefinitamente qualora in caso di errore il
-valore di \var{errno} sia \errcode{EINTR}. Negli altri casi si esce in caso di
-errore effettivo (\texttt{\small 11--14}), altrimenti il programma prosegue.
+alla versione precedente vista in \figref{fig:TCP_ServEcho_first}, è nella
+sezione (\texttt{\small 9--14}) in cui si effettua la chiamata di
+\func{accept}. Quest'ultima viene effettuata (\texttt{\small 9--10})
+all'interno di un ciclo di \code{while}\footnote{la sintassi del C relativa a
+ questo ciclo può non essere del tutto chiara. In questo caso infatti si è
+ usato un ciclo vuoto che non esegue nessuna istruzione, in questo modo
+ quello che viene ripetuto con il ciclo è soltanto il codice che esprime la
+ condizione all'interno del \code{while}.} che la ripete indefinitamente
+qualora in caso di errore il valore di \var{errno} sia \errcode{EINTR}. Negli
+altri casi si esce in caso di errore effettivo (\texttt{\small 11--14}),
+altrimenti il programma prosegue.
Si noti che in questa nuova versione si è aggiunta una ulteriore sezione
(\texttt{\small 15--28}) per il debugging, che stampa l'indirizzo da cui si è
projects / gapil.git / blobdiff