X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=22da5c0194b660c71df60ba5a39403221ef5c9c3;hp=59eb4042a70957ff77e3324727dbccd860733f8b;hb=0697eab692e2d8e66f736e5be01648198aa83332;hpb=67a484c6ccfdb14cdd37678ca5df0db699801935

diff --git a/prochand.tex b/prochand.tex
index 59eb404..22da5c0 100644
--- a/prochand.tex
+++ b/prochand.tex
@@ -208,25 +208,131 @@ ritorno della funzione fork 
 figlio è zero; in questo modo il programma può identificare se viene eseguito
 dal padre o dal figlio.
 
-Si noti come la funzione \fucn{fork} ritorni \textbf{due} volte: nel padre e
-nel figlio. La sola differenza che si ha nei due processi è il valore di
+\begin{figure}[!htb]
+  \footnotesize
+  \begin{lstlisting}{}
+#include <errno.h>       /* error definitions and routines */ 
+#include <stdlib.h>      /* C standard library */
+#include <unistd.h>      /* unix standard library */
+#include <stdio.h>       /* standard I/O library */
+#include <string.h>      /* string functions */
+
+/* Help printing routine */
+void usage(void);
+
+int main(int argc, char *argv[])
+{
+/* 
+ * Variables definition  
+ */
+    int i;
+    int nchild;
+    pid_t pid;
+
+    ...        /* handling options */
+
+    /* There must be remaing parameters */
+    if (optind == argc) {
+        usage();
+    }
+    nchild = atoi(argv[optind]);
+    printf("Test for forking %d child\n", nchild);
+    /* loop to fork children */
+    for (i=0; i<nchild; i++) {
+        if ( (pid = fork()) < 0) {
+            printf("Error on %d child creation, %s\n", i, strerror(errno));
+        }
+        if (pid == 0) {   /* child */
+            printf("Child %d successfully executing\n", i++);
+            sleep(2);
+            printf("Child %d exiting\n", i);
+            exit(0);
+        } else {          /* parent */
+            printf("Spawned %d child, pid %d \n", i, pid);
+        }
+    }
+    /* normal exit */
+    return 0;
+}
+  \end{lstlisting}
+  \caption{Esempio di codice per la creazione di nuovi processi.}
+  \label{fig:proc_fork_code}
+\end{figure}
+
+Si noti come la funzione \func{fork} ritorni \textbf{due} volte: una nel padre
+e una nel figlio. La sola differenza che si ha nei due processi è il valore di
 ritorno restituito dalla funzione, che nel padre è il \acr{pid} del figlio
 mentre nel figlio è zero; in questo modo il programma può identificare se
-viene eseguito dal padre o dal figlio. La scelta di questi valori comunque non
-è casuale, un processo infatti può avere più figli, ed il valore di ritorno di
-\func{fork} è l'unico modo che permette di idenficare quello appena creato; al
-contrario un figlio ha sempre un solo padre (il cui \acr{pid} può sempre
-essere ottenuto con \func{getppid}, vista in \secref{sec:proc_pid}) e si usa
-il valore nullo, che non può essere il \acr{pid} di nessun processo.
-
-In generale non si può dire se il quale fra il padre ed il figlio venga
-eseguito per primo\footnote{anche se nel kernel 2.4.x è stato introdotto un
+viene eseguito dal padre o dal figlio. 
+
+La scelta di questi valori comunque non è casuale, un processo infatti può
+avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che
+permette di identificare quello appena creato; al contrario un figlio ha
+sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
+\func{getppid}, vista in \secref{sec:proc_pid}) e si usa il valore nullo, che
+non può essere il \acr{pid} di nessun processo.
+
+In \curfig\ si è riportato il corpo del codice dell'esempio \cmd{forktest},
+che ci permette di illustrare l'uso della funzione \func{fork}, creando un
+numero di figli specificato a linea di comando; il codice completo, compresa
+la parte che gestisce le opzioni a riga di comando, è disponibile nel file
+\file{ForkTest.c}.
+
+Decifrato il numero di figli da creare, il ciclo principale del programma
+(\texttt{\small 28--40}) esegue in successione la creazione dei processi figli
+controllando il successo della chiamata a \func{fork} (\texttt{\small
+  29--31}); ciascun figlio (\texttt{\small 29--31}) si limita a stampare il
+suo numero di successione, attendere 3 secondi e scrivere un messaggio prima
+di uscire. Il processo padre invece (\texttt{\small 29--31}) stampa un
+messaggio di creazione e procede nell'esecuzione del ciclo. Se eseguiamo il
+comando otterremo come output sul terminale:
+\begin{verbatim}
+[piccardi@selidor sources]$ ./forktest 5
+Test for forking 5 child
+Spawned 1 child, pid 840 
+Child 1 successfully executing
+Child 2 successfully executing
+Spawned 2 child, pid 841 
+Spawned 3 child, pid 842 
+Child 3 successfully executing
+Spawned 4 child, pid 843 
+Child 4 successfully executing
+Child 5 successfully executing
+Spawned 5 child, pid 844 
+[piccardi@selidor sources]$ Child 2 exiting
+Child 1 exiting
+Child 4 exiting
+Child 3 exiting
+Child 5 exiting
+\end{verbatim}
+
+Come si vede non si può dire quale processo fra il padre ed il figlio venga
+eseguito per primo\footnote{anche se nel kernel 2.4.x era stato introdotto un
   meccanismo che metteva in esecuzione sempre il xxx per primo (TODO
-  recuperare le informazioni esatte)}, per cui se i due processi devono essere
-sincronizzati occorre ricorrere ad un qualche meccanismo di
-intercomunicazione.
-
-
+  recuperare le informazioni esatte)} dopo la chiamata a \func{fork}, nel caso
+mostrato sopra ad esempio si può notare come dopo la creazione il secondo ed
+il quinto figlio sia stato stati eseguiti per primi, mantre per gli altri
+figli è stato eseguito per primo il padre. 
+
+In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
+scheduling usato dal kernel, dalla particolare situazione in si trova la
+macchina al momento della chiamata, risultando del tutto impredicibile.
+Eseguendo più volte il programma di prova, si sono ottenute situazioni
+completamente diverse, compreso caso in cui il processo padre ha eseguito più
+di una \func{fork} prima che uno dei figli venisse messo in
+esecuzione. 
+
+Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
+istruzioni del codice fra padre e figli, e se è necessaria una qualche forma
+di precedenza occorrerà provvedere ad espliciti meccanismi di
+sincronizzazione, pena il rischio di incorrere nelle cosiddette \textit{race
+  conditions}.
+
+Si ricordi inoltre che come accennato, essendo i segmenti di memoria
+utilizzati dai singoli processi completamente separati, le modifiche delle
+variabili nei processi figli (come l'incremento di \var{i} in \texttt{\small
+  33}) saranno effettive solo per essi, e non hanno alcun effetto sul valore
+che le stesse variabili hanno nel processo padre.
 
 
 \subsection{Le funzioni \texttt{wait} e  \texttt{waitpid}}