Infatti subito dopo la creazione del socket \var{list\_fd} ha una referenza, e
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
+entrambi i socket si trovano con due referenze. Questo fa sì che quando il
padre chiude \var{sock\_fd} esso resta con una referenza da parte del figlio,
e sarà definitivamente chiuso solo quando quest'ultimo, dopo aver completato
le sue operazioni, chiamerà (\texttt{\small 45}) la funzione \func{close}.
errori pendenti su un socket usando l'opzione \const{SO\_ERROR}.
\end{itemize*}
-Infine c'è una sola condizione che fa si che \func{select} ritorni segnalando
+Infine c'è una sola condizione che fa sì che \func{select} ritorni segnalando
che un socket (che sarà riportato nel terzo insieme di file descriptor) ha una
condizione di eccezione pendente, e cioè la ricezione sul socket di
\textsl{dati urgenti} (o \textit{out-of-band}), una caratteristica specifica
quello di consentire maggiore flessibilità nell'uso di \func{select} da parte
dei programmi, se infatti si sa che una applicazione non è in grado di fare
niente fintanto che non può ricevere o inviare una certa quantità di dati, si
-possono utilizzare questi valori per far si che \func{select} ritorni solo
+possono utilizzare questi valori per far sì che \func{select} ritorni solo
quando c'è la certezza di avere dati a sufficienza.\footnote{questo tipo di
controllo è utile di norma solo per la lettura, in quanto in genere le
operazioni di scrittura sono già controllate dall'applicazione, che sa
projects / gapil.git / blobdiff