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
richiedere il riavvio automatico delle system call interrotte secondo la
semantica di BSD, usando l'opzione \const{SA\_RESTART} di \func{sigaction};
rispetto a quanto visto in \figref{fig:sig_Signal_code}. Definiremo allora la
-nuova funzione \func{SignalRestart} come mostrato in
-\figref{fig:sig_SignalRestart_code}, ed installeremo il gestore usando
-quest'ultima.
+nuova funzione \func{SignalRestart}\footnote{anche questa è definita, insieme
+ alle altre funzioni riguardanti la gestione dei segnali, nel file
+ \file{SigHand.c}, il cui contento completo può essere trovato negli esempi
+ allegati.} come mostrato in \figref{fig:sig_SignalRestart_code}, ed
+installeremo il gestore usando quest'ultima.
\begin{figure}[!htb]
\footnotesize \centering
\end{figure}
Come si può notare questa funzione è identica alla precedente \func{Signal},
-solo che in questo caso invece di inizializzare a zero il campo
-\var{sa\_flags} di \struct{sigaction}, lo si inizializza (\texttt{\small 5})
-al valore \const{SA\_RESTART}. Usando questa funzione al posto di
-\func{Signal} nel server non è necessaria nessuna altra modifica: le system
-call interrotte saranno automaticamente riavviate, e l'errore \errcode{EINTR}
-non si manifesterà più.
+illustrata in \figref{fig:sig_Signal_code}, solo che in questo caso invece di
+inizializzare a zero il campo \var{sa\_flags} di \struct{sigaction}, lo si
+inizializza (\texttt{\small 5}) al valore \const{SA\_RESTART}. Usando questa
+funzione al posto di \func{Signal} nel server non è necessaria nessuna altra
+modifica: le system call interrotte saranno automaticamente riavviate, e
+l'errore \errcode{EINTR} non si manifesterà più.
La seconda soluzione è più invasiva e richiede di controllare tutte le volte
l'errore restituito dalle varie system call, ripetendo la chiamata qualora
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
-\figref{fig:TCP_echo_server_code}, dove si è riportata la sezione di codice
-modificata per la seconda versione del programma.
+ 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à nella gestione dei segnali però viene al costo di una
+riscrittura parziale del server, la nuova versione di questo, in cui si sono
+introdotte una serie di nuove opzioni che ci saranno utili per il debug, è
+mostrata in \figref{fig:TCP_echo_server_code_second}, dove si sono riportate
+la sezioni di codice modificate nella seconda versione del programma, il
+sorgente completo di quest'ultimo si trova nel file
+\file{TCP\_echod\_second.c} dei sorgenti allegati alla guida.
+
+La prima modifica effettuata è stata quella di introdurre una nuova opzione a
+riga di comando, \texttt{-c}, che permette di richiedere il comportamento
+compatibile nella gestione di \const{SIGCHLD} al posto della semantica BSD
+impostando la variabile \var{compat} ad un valore non nullo. Questa è
+preimpostata al valore nullo, cosicché se non si usa questa opzione il
+comportamento di default del server è di usare la semantica BSD.
+
+Una seconda opzione aggiunta è quella di inserire un tempo di attesa fisso
+specificato in secondi fra il ritorno della funzione \func{listen} e la
+chiamata di \func{accept}, specificabile con l'opzione \texttt{-w}, che
+permette di impostare la variabile \var{waiting}. Infine si è introdotta una
+opzione \texttt{-d} per abilitare il debugging che imposta ad un valore non
+nullo la variabile \var{debugging}. Al solito la gestione di tutte queste
+opzioni si è omessa da \figref{fig:TCP_echo_server_code_second}, ma può essere
+visionata nel sorgente del programma.
\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
per il servizio \textit{echo} modificata per tener conto dell'interruzione
delle system call.}
- \label{fig:TCP_echo_server_code}
+ \label{fig:TCP_echo_server_code_second}
\end{figure}
-In realtà l'unica chiamata critica che può essere interrotta nel server è
-quella ad \func{accept}, dato che questa è l'unica che può mettere il processo
-padre in stato di sleep.\footnote{si noti infatti che le altre \textit{slow
- 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.
+Vediamo allora come è cambiato il nostro server; una volta definite le
+variabili e trattate le opzioni il primo passo (\texttt{\small 9--13}) è
+verificare la semantica scelta per la gestione di \const{SIGCHLD}, a seconda
+del valore di \var{compat} (\texttt{\small 9}) si installa il gestore con la
+funzione \func{Signal} (\texttt{\small 10}) o con \texttt{SignalRestart}
+(\texttt{\small 12}), essendo quest'ultimo il valore di default.
+
+Tutta la sezione seguente, che crea il socket, cede i privilegi di
+amministratore ed eventualmente lancia il programma come demone, è rimasta
+invariata e pertanto non la si è riportata in
+\figref{fig:TCP_echo_server_code_second}; l'unica modifica effettuata è stata
+quella di aver introdotto (\texttt{\small 21}) l'eventuale pausa specificata
+con l'opzione \code{-w Nsec}, che inizializza la variabile \var{waiting} al
+numero di secondi da aspettare, subito dopo la chiamata (\texttt{\small
+ 17--20}) alla funzione \func{listen}.
+
+Si è potuto far questo perché l'unica chiamata critica che può essere
+interrotta da \const{SIGCHLD} nel server è quella ad \func{accept}, che è
+l'unica funzione che può mettere il processo padre in stato di
+sleep.\footnote{si noti infatti che le altre \textit{slow 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 ciclo principale (\texttt{\small
+ 23--42}) rispetto precedente versione di \figref{fig:TCP_ServEcho_first}, è
+nella sezione (\texttt{\small 26--30}) in cui si effettua la chiamata di
+\func{accept}. Quest'ultima viene effettuata (\texttt{\small 26--27})
+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 27--29}),
+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 è
-avuta la connessione, e la gestione (\texttt{\small 5}) di una nuova opzione,
-specificabile con \code{-w Nsec}, che inizializza la variabile \var{waiting}
-al numero di secondi da aspettare. Questa opzione permette di specificare un
-tempo di attesa prima di passare alla chiamata \func{accept}, il cui scopo
-sarà più chiaro facendo riferimento al primo degli scenari critici di
-\secref{sec:TCP_echo_critical}.
+(\texttt{\small 31--39}) di aiuto per il debug del programma, che eseguita con
+un controllo (\texttt{\small 31}) sul valore della variabile \var{debugging}
+impostato dall'opzione \texttt{-d}. Qualora questo sia nullo, come
+preimpostato, non accade nulla. altrimenti (\texttt{\small 32}) l'indirizzo
+ricevuto da \var{accept} viene convertito in una stringa che poi
+(\texttt{\small 33--38}) viene opportunamente stampata o sullo schermo o nei
+log.
+