--- /dev/null
+*.aux
+*.bbl
+*.blg
+*.dvi
+*.pdf
+*.ps
+*.idx
+*.log
+*.idx
+*.ilg
+*.ind
+*.roc
+*.tgz
+2004-04-25 Simone Piccardi <piccardi@gont.earthsea.ea>
+
+ * process.tex: correzioni da Paolo Giarrusso, refuso su BSS e tipo
+ della funzione setjmp.
+
2004-02-17 Simone Piccardi <piccardi@anarres.truelite.it>
* netlayer.tex: correzioni agli indirizzi IPv6 suggerite da
--- /dev/null
+*.pdf
+*.ps
+*.eps
volte che un pacchetto viene inviato al server, in modo da poter ricavare da
esso l'indirizzo del client a cui inviare la risposta in \var{addr}. Per
questo motivo in questo caso (al contrario di quanto fatto in
-\figref{fig:UDP_daytime_client}) si è avuto cura di passare gli opportuni
-argomenti alla funzione. Dopo aver controllato (\texttt{\small 27--30}) la
-presenza di eventuali errori (uscendo con un messaggio di errore qualora ve ne
-siano) si verifica (\texttt{\small 31}) se è stata attivata l'opzione
-\texttt{-v} (che imposta la variabile \var{verbose}) stampando nel caso
-(\texttt{\small 32--35}) l'indirizzo da cui si è appena ricevuto una richiesta
-(questa sezione è identica a quella del server TCP illustrato in
+\figref{fig:UDP_daytime_client}) si è avuto cura di passare gli argomenti
+\var{addr} e \var{len} alla funzione. Dopo aver controllato (\texttt{\small
+ 27--30}) la presenza di eventuali errori (uscendo con un messaggio di errore
+qualora ve ne siano) si verifica (\texttt{\small 31}) se è stata attivata
+l'opzione \texttt{-v} (che imposta la variabile \var{verbose}) stampando nel
+caso (\texttt{\small 32--35}) l'indirizzo da cui si è appena ricevuto una
+richiesta (questa sezione è identica a quella del server TCP illustrato in
\figref{fig:TCP_daytime_cunc_server_code}).
Una volta ricevuta la richiesta resta solo da ottenere il tempo corrente
di trattare separatamente le singole connessioni. Questo significa anche che è
il kernel a gestire la possibilità di richieste multiple in contemporanea;
quello che succede è semplicemente che il kernel accumula in un buffer in
-ingresso i pacchetti che arrivano e li restituisce al processo uno alla volta
-per ciascuna chiamata di \func{recvfrom}; è poi compito del server distribuire
-le risposte sulla base dell'indirizzo da cui provengono le richieste.
+ingresso i pacchetti UDP che arrivano e li restituisce al processo uno alla
+volta per ciascuna chiamata di \func{recvfrom}; nel nostro caso sarà poi
+compito del server distribuire le risposte sulla base dell'indirizzo da cui
+provengono le richieste.
Come illustrato in \secref{sec:UDP_characteristics} essendo i socket UDP privi
di connessione non è necessario per i client usare \func{connect} prima di
-iniziare una comunicazione con un server.
+iniziare una comunicazione con un server.
puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
variabili che vanno nel segmento dati, e non è affatto vero in generale.}
- Storicamente questo segmento viene chiamato BBS (da \textit{block started by
+ Storicamente questo segmento viene chiamato BSS (da \textit{block started by
symbol}). La sua dimensione è fissa.
\item Lo \textit{heap}. Tecnicamente lo si può considerare l'estensione del
salvare il contesto dello stack è \funcd{setjmp}, il cui prototipo è:
\begin{functions}
\headdecl{setjmp.h}
- \funcdecl{void setjmp(jmp\_buf env)}
+ \funcdecl{int setjmp(jmp\_buf env)}
Salva il contesto dello stack.
\label{fig:proc_task_struct}
\end{figure}
-
Come accennato in \secref{sec:intro_unix_struct} è lo
\textit{scheduler}\index{scheduler} che decide quale processo mettere in
esecuzione; esso viene eseguito ad ogni system call ed ad ogni
\subsection{Una panoramica sulle funzioni fondamentali}
\label{sec:proc_handling_intro}
-I processi vengono creati dalla funzione \func{fork}; in molti unix questa è
-una system call, Linux però usa un'altra nomenclatura, e la funzione
-\func{fork} è basata a sua volta sulla system call \func{\_\_clone}, che viene
-usata anche per generare i \textit{thread}. Il processo figlio creato dalla
-\func{fork} è una copia identica del processo processo padre, ma ha un nuovo
-\acr{pid} e viene eseguito in maniera indipendente (le differenze fra padre e
-figlio sono affrontate in dettaglio in \secref{sec:proc_fork}).
+In un sistema unix-like i processi vengono sempre creati da altri processi
+tramite la funzione \func{fork}; il nuovo processo (che viene chiamato
+\textsl{figlio}) creato dalla \func{fork} è una copia identica del processo
+processo originale (detto \textsl{padre}), ma ha un nuovo \acr{pid} e viene
+eseguito in maniera indipendente (le differenze fra padre e figlio sono
+affrontate in dettaglio in \secref{sec:proc_fork}).
Se si vuole che il processo padre si fermi fino alla conclusione del processo
figlio questo deve essere specificato subito dopo la \func{fork} chiamando la
projects / gapil.git / commitdiff