X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=process.tex;h=831c6482e8e4b096847d7bf8a392d1b9225cba85;hp=c5f9187743a3da98a40164f0fd77c047295df12d;hb=17bae834f41549575a11ddf444d97de8d575269e;hpb=fd86592a845b5f76ad43ba2374ca0b798ffca595

diff --git a/process.tex b/process.tex
index c5f9187..831c648 100644
--- a/process.tex
+++ b/process.tex
@@ -1,6 +1,6 @@
 %% process.tex
 %%
-%% Copyright (C) 2000-2002 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2003 Simone Piccardi.  Permission is granted to
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Prefazione",
@@ -59,9 +59,7 @@ si suppone iniziare l'esecuzione; in ogni caso senza questa funzione lo stesso
 Lo standard ISO C specifica che la funzione \func{main} può non avere 
 argomenti o prendere due argomenti che rappresentano gli argomenti passati da
 linea di comando, in sostanza un prototipo che va sempre bene è il seguente:
-\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
-    int main (int argc, char *argv[])
-\end{lstlisting}
+\includecodesnip{listati/main_def.c}
 
 In realtà nei sistemi Unix esiste un'altro modo per definire la funzione
 \func{main}, che prevede la presenza di un terzo parametro, \code{char
@@ -175,9 +173,9 @@ pulizia al programmatore che la utilizza.
 all'utente, avere la possibilità di effettuare automaticamente la chiamata ad
 una funzione che effettui tali operazioni all'uscita dal programma. A questo
 scopo lo standard ANSI C prevede la possibilità di registrare un certo numero
-funzioni che verranno eseguite all'uscita dal programma (sia per la chiamata
-ad \func{exit} che per il ritorno di \func{main}). La prima funzione che si
-può utilizzare a tal fine è \funcd{atexit} il cui prototipo è:
+di funzioni che verranno eseguite all'uscita dal programma (sia per la
+chiamata ad \func{exit} che per il ritorno di \func{main}). La prima funzione
+che si può utilizzare a tal fine è \funcd{atexit} il cui prototipo è:
 \begin{prototype}{stdlib.h}{void atexit(void (*function)(void))}
   Registra la funzione \param{function} per la chiamata all'uscita dal
   programma.
@@ -187,8 +185,8 @@ pu
 \end{prototype}
 \noindent la funzione richiede come argomento l'indirizzo di una opportuna
 funzione di pulizia da chiamare all'uscita del programma, che non deve
-prendere argomenti e non deve ritornare niente (deve essere essere cioè
-definita come \code{void function(void)}).
+prendere argomenti e non deve ritornare niente (deve essere cioè definita come
+\code{void function(void)}).
 
 Un'estensione di \func{atexit} è la funzione \funcd{on\_exit}, che le
 \acr{glibc} includono per compatibilità con SunOS, ma che non è detto sia
@@ -358,9 +356,7 @@ seguenti segmenti:
   La prima parte è il segmento dei dati inizializzati, che contiene le
   variabili il cui valore è stato assegnato esplicitamente. Ad esempio
   se si definisce:
-  \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
-    double pi = 3.14;
-  \end{lstlisting}
+\includecodesnip{listati/pi.c}
   questo valore sarà immagazzinato in questo segmento. La memoria di questo
   segmento viene preallocata all'avvio del programma e inizializzata ai valori
   specificati.
@@ -368,9 +364,7 @@ seguenti segmenti:
   La seconda parte è il segmento dei dati non inizializzati, che contiene le
   variabili il cui valore non è stato assegnato esplicitamente. Ad esempio se
   si definisce:
-  \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
-    int vect[100];
-  \end{lstlisting}
+\includecodesnip{listati/vect.c}
   questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
   allocato all'avvio, e tutte le variabili vengono inizializzate a zero (ed i
   puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
@@ -555,8 +549,8 @@ tollerante nei confronti di piccoli errori come quello di chiamate doppie a
 
 Il problema più comune e più difficile da risolvere che si incontra con le
 routine di allocazione è quando non viene opportunamente liberata la memoria
-non più utilizzata, quello che in inglese viene chiamato \textit{memory-leak},
-cioè una \textsl{perdita di memoria}.
+non più utilizzata, quello che in inglese viene chiamato \textit{memory
+  leak}\index{memory leak}, cioè una \textsl{perdita di memoria}.
 
 Un caso tipico che illustra il problema è quello in cui in una subroutine si
 alloca della memoria per uso locale senza liberarla prima di uscire. La
@@ -569,7 +563,7 @@ Il problema 
 momento, in corrispondenza ad una qualunque chiamata di \func{malloc}, che può
 essere in una sezione del codice che non ha alcuna relazione con la subroutine
 che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
-\textit{memory leak}.
+\textit{memory leak}\index{memory leak}.
 
 In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
 programmazione ad oggetti, il problema dei \textit{memory leak} è notevolmente
@@ -615,10 +609,10 @@ molto complesse riguardo l'allocazione della memoria.
 \label{sec:proc_mem_alloca}
 
 Una possibile alternativa all'uso di \func{malloc}, che non soffre dei
-problemi di \textit{memory leak} descritti in precedenza, è la funzione
-\funcd{alloca}, che invece di allocare la memoria nello heap usa il segmento
-di stack della funzione corrente. La sintassi è identica a quella di
-\func{malloc}, il suo prototipo è:
+problemi di \textit{memory leak}\index{memory leak} descritti in precedenza, è
+la funzione \funcd{alloca}, che invece di allocare la memoria nello heap usa
+il segmento di stack della funzione corrente. La sintassi è identica a quella
+di \func{malloc}, il suo prototipo è:
 \begin{prototype}{stdlib.h}{void *alloca(size\_t size)}
   Alloca \param{size} byte nello stack.
   
@@ -634,10 +628,10 @@ quindi non esiste un analogo della \func{free}) in quanto essa viene
 rilasciata automaticamente al ritorno della funzione.
 
 Come è evidente questa funzione ha molti vantaggi, anzitutto permette di
-evitare alla radice i problemi di memory leak, dato che non serve più la
-deallocazione esplicita; inoltre la deallocazione automatica funziona anche
-quando si usa \func{longjmp} per uscire da una subroutine con un salto non
-locale da una funzione (vedi \secref{sec:proc_longjmp}).
+evitare alla radice i problemi di memory leak\index{memory leak}, dato che non
+serve più la deallocazione esplicita; inoltre la deallocazione automatica
+funziona anche quando si usa \func{longjmp} per uscire da una subroutine con
+un salto non locale da una funzione (vedi \secref{sec:proc_longjmp}).
 
 Un altro vantaggio è che in Linux la funzione è molto più veloce di
 \func{malloc} e non viene sprecato spazio, infatti non è necessario gestire un
@@ -961,37 +955,11 @@ ritornato il carattere \texttt{':'}, infine se viene incontrato il valore
 elementi di \param{argv} che cominciano con il carattere \texttt{'-'}.
 
 \begin{figure}[htb]
-  \footnotesize
-    \begin{lstlisting}{}
-    opterr = 0;  /* don't want writing to stderr */
-    while ( (i = getopt(argc, argv, "hp:c:e:")) != -1) {
-        switch (i) {
-        /* 
-         * Handling options 
-         */ 
-        case 'h':   /* help option */
-            printf("Wrong -h option use\n");
-            usage();
-            return -1;
-            break;
-        case 'c':   /* take wait time for children */
-            wait_child = strtol(optarg, NULL, 10);    /* convert input */
-            break;
-        case 'p':   /* take wait time for children */
-            wait_parent = strtol(optarg, NULL, 10);   /* convert input */
-            break;
-        case 'e':   /* take wait before parent exit */
-            wait_end = strtol(optarg, NULL, 10);      /* convert input */
-            break;
-        case '?':   /* unrecognized options */
-            printf("Unrecognized options -%c\n",optopt);
-            usage();
-        default:    /* should not reached */
-            usage();
-        }
-    }
-    debug("Optind %d, argc %d\n",optind,argc);
-  \end{lstlisting}
+  \footnotesize \centering
+  \begin{minipage}[c]{15.6cm}
+  \includecodesample{listati/option_code.c}
+  \end{minipage}
+  \normalsize
   \caption{Esempio di codice per la gestione delle opzioni.}
   \label{fig:proc_options_code}
 \end{figure}
@@ -1067,9 +1035,7 @@ terminata da un puntatore nullo.
 L'indirizzo della lista delle variabili di ambiente è passato attraverso la
 variabile globale \var{environ}, a cui si può accedere attraverso una semplice
 dichiarazione del tipo:
-\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
-extern char ** environ;
-\end{lstlisting}
+\includecodesnip{listati/env_ptr.c}
 un esempio della struttura di questa lista, contenente alcune delle variabili
 più comuni che normalmente sono definite dal sistema, è riportato in
 \figref{fig:proc_envirno_list}.
@@ -1320,7 +1286,7 @@ funzione chiamante un valore relativo ad uno dei suoi parametri.  Per far
 questo si usa il cosiddetto \textit{value result argument}, si passa cioè,
 invece di una normale variabile, un puntatore alla stessa; vedremo alcuni
 esempi di questa modalità nelle funzioni che gestiscono i socket (in
-\secref{sec:TCPel_functions}), in cui, per permettere al kernel di restituire
+\secref{sec:TCP_functions}), in cui, per permettere al kernel di restituire
 informazioni sulle dimensioni delle strutture degli indirizzi utilizzate,
 viene usato questo meccanismo.
 
@@ -1353,9 +1319,7 @@ abbia sempre almeno un argomento fisso; prima di effettuare la dichiarazione
 deve essere incluso l'apposito header file \file{stdarg.h}; un esempio di
 dichiarazione è il prototipo della funzione \func{execl} che vedremo in
 \secref{sec:proc_exec}:
-\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
-  int execl(const char *path, const char *arg, ...);
-\end{lstlisting}
+\includecodesnip{listati/exec_sample.c}
 in questo caso la funzione prende due parametri fissi ed un numero variabile
 di altri parametri (che verranno a costituire gli elementi successivi al primo
 del vettore \param{argv} passato al nuovo processo). Lo standard ISO C richiede
@@ -1437,7 +1401,7 @@ stack all'indirizzo dove sono stati salvati i parametri, 
 normale pensare di poter effettuare questa operazione.
 
 In generale però possono esistere anche realizzazioni diverse, per questo
-motivo \macro{va\_list} è definito come \textsl{tipo opaco}\index{tipo opaco}
+motivo \macro{va\_list} è definito come \textsl{tipo opaco}\index{tipo!opaco}
 e non può essere assegnato direttamente ad un'altra variabile dello stesso
 tipo. Per risolvere questo problema lo standard ISO C99\footnote{alcuni
   sistemi che non hanno questa macro provvedono al suo posto
@@ -1581,7 +1545,7 @@ un punto precedentemente stabilito con \func{setjmp} si usa la funzione
 \end{functions}
 
 La funzione ripristina il contesto dello stack salvato da una chiamata a
-\func{setjmp} nell'argomento \param{env}. Dopo l'esecuzione della funzione
+\func{setjmp} nell'argomento \param{env}. Dopo l'esecuzione della funzione il
 programma prosegue nel codice successivo al ritorno della \func{setjmp} con
 cui si era salvato \param{env}, che restituirà il valore \param{val} invece di
 zero.  Il valore di \param{val} specificato nella chiamata deve essere diverso
@@ -1620,18 +1584,18 @@ e statiche mantengono i valori che avevano al momento della chiamata di
 \func{longjmp}, ma quelli delle variabili automatiche (o di quelle dichiarate
 \direct{register}\footnote{la direttiva \direct{register} del compilatore
   chiede che la variabile dichiarata tale sia mantenuta, nei limiti del
-  possibile, all'interno di un registro del processore. Questa direttiva
-  origina dai primi compilatori, quando stava al programmatore scrivere codice
-  ottimizzato, riservando esplicitamente alle variabili più usate l'uso dei
-  registri del processore. Oggi questa direttiva oggi è in disuso dato che
-  tutti i compilatori sono normalmente in grado di valutare con maggior
-  efficacia degli stessi programmatori quando sia il caso di eseguire questa
-  ottimizzazione.}) sono in genere indeterminati.
+  possibile, all'interno di un registro del processore. Questa direttiva è
+  originaria dell'epoca dai primi compilatori, quando stava al programmatore
+  scrivere codice ottimizzato, riservando esplicitamente alle variabili più
+  usate l'uso dei registri del processore. Oggi questa direttiva è in disuso
+  dato che tutti i compilatori sono normalmente in grado di valutare con
+  maggior efficacia degli stessi programmatori quando sia il caso di eseguire
+  questa ottimizzazione.}) sono in genere indeterminati.
 
 Quello che succede infatti è che i valori delle variabili che sono tenute in
 memoria manterranno il valore avuto al momento della chiamata di
 \func{longjmp}, mentre quelli tenuti nei registri del processore (che nella
-chiamata ad un'altra funzioni vengono salvati nel contesto nello stack)
+chiamata ad un'altra funzione vengono salvati nel contesto nello stack)
 torneranno al valore avuto al momento della chiamata di \func{setjmp}; per
 questo quando si vuole avere un comportamento coerente si può bloccare
 l'ottimizzazione che porta le variabili nei registri dichiarandole tutte come