X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=e57e8ca84558fd05cf2e11e27dab49b7a9eaad6b;hp=98a07883b31341efba1a9245828d1c3ea730cd98;hb=81ff87c3e2a6ecd3e33867798cba0d27576f44d0;hpb=989ba37f5c3e6190b8f500db103529c3253ebb4d

diff --git a/prochand.tex b/prochand.tex
index 98a0788..e57e8ca 100644
--- a/prochand.tex
+++ b/prochand.tex
@@ -137,10 +137,12 @@ system call ed ad ogni interrupt,\footnote{pi
   occasioni. NDT completare questa parte.} (ma può essere anche attivato
 esplicitamente). Il timer di sistema provvede comunque a che esso sia invocato
 periodicamente, generando un interrupt periodico secondo la frequenza
-specificata dalla costante \macro{HZ}, definita in \file{asm/param.h}. Il
-valore usuale è 100\footnote{è così per tutte le architetture eccetto l'alpha,
-  per la quale è 1000} ed è espresso in Hertz. Si ha cioè un interrupt dal
-timer ogni centesimo di secondo.
+specificata dalla costante \macro{HZ}, definita in \file{asm/param.h}, ed il
+cui valore è espresso in Hertz.\footnote{Il valore usuale di questa costante è
+  100, per tutte le architetture eccetto l'alpha, per la quale è 1000. Occorre
+  fare attenzione a non confondere questo valore con quello dei clock tick
+  (vedi \secref{sec:sys_unix_time}).}
+%Si ha cioè un interrupt dal timer ogni centesimo di secondo.
 
 Ogni volta che viene eseguito, lo \textit{scheduler} effettua il calcolo delle
 priorità dei vari processi attivi (torneremo su questo in
@@ -377,7 +379,9 @@ int main(int argc, char *argv[])
 Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
 sono già troppi processi nel sistema (il che di solito è sintomo che
 qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
-sul numero totale di processi permessi all'utente (vedi \secref{sec:sys_xxx}).
+sul numero totale di processi permessi all'utente (vedi
+\secref{sec:sys_resource_limit}, ed in particolare
+\tabref{tab:sys_rlimit_values}).
 
 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
 quella in cui all'interno di un programma si creano processi figli cui viene
@@ -412,8 +416,8 @@ degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
 descrizione delle opzioni); il codice completo, compresa la parte che gestisce
 le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
 distribuito insieme agli altri sorgenti degli esempi su
-\href{http://firenze.linux.it/~piccardi/gapil_source.tgz}
-{\texttt{http://firenze.linux.it/\~~\hspace{-2.0mm}piccardi/gapil\_source.tgz}}.
+\href{http://gapil.firenze.linux.it/gapil_source.tgz}
+{\texttt{http://gapil.firenze.linux.it/gapil\_source.tgz}}.
 
 Decifrato il numero di figli da creare, il ciclo principale del programma
 (\texttt{\small 24--40}) esegue in successione la creazione dei processi figli
@@ -474,8 +478,9 @@ Pertanto non si pu
 istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
 essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
 occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
-rischio di incorrere nelle cosiddette \textit{race condition} \index{race
-  condition} (vedi \secref{sec:proc_race_cond}.
+rischio di incorrere nelle cosiddette 
+\textit{race condition}\index{race condition} 
+(vedi \secref{sec:proc_race_cond}).
 
 Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli
 processi completamente separati, le modifiche delle variabili nei processi
@@ -609,7 +614,7 @@ comune dopo l'esecuzione di una \func{fork} 
 \item la maschera dei segnali bloccati (vedi \secref{sec:sig_sigmask}) e le
   azioni installate (vedi \secref{sec:sig_gen_beha}).
 \item i segmenti di memoria condivisa agganciati al processo (vedi
-\secref{sec:ipc_xxx}). 
+\secref{sec:ipc_shar_mem}). 
 \item i limiti sulle risorse (vedi \secref{sec:sys_resource_limit}).
 \item le variabili di ambiente (vedi \secref{sec:proc_environ}).
 \end{itemize*}
@@ -619,8 +624,8 @@ le differenze fra padre e figlio dopo la \func{fork} invece sono:
 \item il \textit{process id}. 
 \item il \textit{parent process id} (quello del figlio viene settato al
   \acr{pid} del padre).
-\item i valori dei tempi di esecuzione (vedi \secref{sec:sys_xxx}) che
-  nel figlio sono posti a zero.
+\item i valori dei tempi di esecuzione della struttura \var{tms} (vedi
+  \secref{sec:sys_cpu_times}) che nel figlio sono posti a zero.
 \item i \textit{file lock} (vedi \secref{sec:file_locking}), che non
   vengono ereditati dal figlio.
 \item gli allarmi ed i segnali pendenti (vedi \secref{sec:sig_gen_beha}), che
@@ -645,10 +650,10 @@ padre, che costituiva un inutile appesantimento in tutti quei casi in cui la
 \func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
 venne introdotta in BSD per migliorare le prestazioni.
 
-Dato che Linux supporta il \textit{copy on write} la perdita di prestazioni è
-assolutamente trascurabile, e l'uso di questa funzione (che resta un caso
-speciale della funzione \func{clone}), è deprecato; per questo eviteremo di
-trattarla ulteriormente.
+Dato che Linux supporta il \textit{copy on write}\index{copy on write} la
+perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
+funzione (che resta un caso speciale della funzione \func{clone}), è
+deprecato; per questo eviteremo di trattarla ulteriormente.
 
 
 \subsection{La conclusione di un processo.}
@@ -1209,9 +1214,9 @@ la lista completa 
   \secref{sec:file_locking}).
 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
   \secref{sec:sig_sigmask}).
-\item i limiti sulle risorse (vedi \secref{sec:sys_resource_limits}).
+\item i limiti sulle risorse (vedi \secref{sec:sys_resource_limit}).
 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
-  \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:sys_xxx}).
+  \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:sys_cpu_times}).
 \end{itemize*}
 
 Inoltre i segnali che sono stati settati per essere ignorati nel processo
@@ -2099,11 +2104,11 @@ processo qualsiasi sia la sua priorit
   interrupt vengono intercettati dall'interfaccia real-time, e gestiti
   direttamente qualora ci sia la necessità di avere un processo con priorità
   più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
-page fault si possono avere ritardi non previsti. Se l'ultimo problema può
-essere aggirato attraverso l'uso delle funzioni di controllo della memoria
-virtuale (vedi \secref{sec:proc_mem_lock}), il primo non è superabile e può
-comportare ritardi non prevedibili riguardo ai tempi di esecuzione di
-qualunque processo.
+page fault\index{page fault} si possono avere ritardi non previsti. Se
+l'ultimo problema può essere aggirato attraverso l'uso delle funzioni di
+controllo della memoria virtuale (vedi \secref{sec:proc_mem_lock}), il primo
+non è superabile e può comportare ritardi non prevedibili riguardo ai tempi di
+esecuzione di qualunque processo.
 
 In ogni caso occorre usare le priorità assolute con molta attenzione: se si dà
 ad un processo una priorità assoluta e questo finisce in un loop infinito,
@@ -2301,7 +2306,7 @@ il suo prototipo 
 
 La funzione restituisce il valore dell'intervallo di tempo usato per la
 politica \textit{round robin} in una struttura \var{timespec}, (la cui
-definizione si può trovare in \secref{fig:sig_timespec_def}).
+definizione si può trovare in \figref{fig:sys_timeval_struct}).
 
 
 Come accennato ogni processo che usa lo scheduling real-time può rilasciare
@@ -2351,7 +2356,8 @@ di interruzione in una fase intermedia.
 In un ambiente multitasking il concetto è essenziale, dato che un processo può
 essere interrotto in qualunque momento dal kernel che mette in esecuzione un
 altro processo o dalla ricezione di un segnale; occorre pertanto essere
-accorti nei confronti delle possibili \textit{race condition} (vedi
+accorti nei confronti delle possibili 
+\textit{race condition}\index{race condition} (vedi
 \secref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase in
 cui non erano ancora state completate.
 
@@ -2385,7 +2391,8 @@ condiviso, onde evitare problemi con le ottimizzazioni del codice.
 
 
 
-\subsection{Le \textit{race condition} e i \textit{deadlock}}
+\subsection{Le \textit{race condition}\index{race condition} e i 
+  \textit{deadlock}}
 \label{sec:proc_race_cond}
 
 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi