X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=process.tex;h=6a37bb0968d2f534ac0571099399027f159732ff;hp=4b18c30426bc8e815a503fac7dcbab75eb391a99;hb=dfc23dbc3caad01544e73d2488f8490d9260ebae;hpb=6760429dc70f868716393c4413c5450b0649869b

diff --git a/process.tex b/process.tex
index 4b18c30..6a37bb0 100644
--- a/process.tex
+++ b/process.tex
@@ -697,12 +697,14 @@ cui si trovano in memoria, eliminando quelle che non servono.  Questo
 meccanismo è detto \textsl{paginazione} (o \textit{paging}), ed è uno dei
 compiti principali del kernel.
 
+\itindbeg{page~fault} 
+
 Quando un processo cerca di accedere ad una pagina che non è nella memoria
-reale, avviene quello che viene chiamato un \itindex{page~fault} \textit{page
-  fault}; la gestione della memoria genera un'interruzione e passa il
-controllo al kernel il quale sospende il processo e si incarica di mettere in
-RAM la pagina richiesta, effettuando tutte le operazioni necessarie per
-reperire lo spazio necessario, per poi restituire il controllo al processo.
+reale, avviene quello che viene chiamato un \textit{page fault}; la gestione
+della memoria genera un'interruzione e passa il controllo al kernel il quale
+sospende il processo e si incarica di mettere in RAM la pagina richiesta,
+effettuando tutte le operazioni necessarie per reperire lo spazio necessario,
+per poi restituire il controllo al processo.
 
 Dal punto di vista di un processo questo meccanismo è completamente
 trasparente, e tutto avviene come se tutte le pagine fossero sempre
@@ -712,6 +714,8 @@ se la pagina è direttamente disponibile, a tempi estremamente più lunghi,
 dovuti all'intervento del kernel, qualora sia necessario reperire pagine
 riposte nella \textit{swap}.
 
+\itindend{page~fault} 
+
 Normalmente questo è il prezzo da pagare per avere un multitasking reale, ed
 in genere il sistema è molto efficiente in questo lavoro; quando però ci siano
 esigenze specifiche di prestazioni è possibile usare delle funzioni che
@@ -731,8 +735,8 @@ commette quando si è manipolato male un puntatore e genera quella che viene
 chiamata una \itindex{segment~violation} \textit{segment violation}. Se si
 tenta cioè di leggere o scrivere con un indirizzo per il quale non esiste
 un'associazione nella memoria virtuale, il kernel risponde al relativo
-\itindex{page~fault} \textit{page fault} mandando un segnale \signal{SIGSEGV}
-al processo, che normalmente ne causa la terminazione immediata.
+\textit{page fault} mandando un segnale \signal{SIGSEGV} al processo, che
+normalmente ne causa la terminazione immediata.
 
 È pertanto importante capire come viene strutturata la memoria virtuale di un
 processo. Essa viene divisa in \textsl{segmenti}, cioè un insieme contiguo di
@@ -1016,11 +1020,11 @@ sez.~\ref{sec:proc_environ}), in particolare diventa possibile tracciare
 questo tipo di errori usando la variabile di ambiente \envvar{MALLOC\_CHECK\_}
 che quando viene definita mette in uso una versione meno efficiente delle
 funzioni suddette, che però è più tollerante nei confronti di piccoli errori
-come quello dei \itindex{double~free} \textit{double~free} o i
-\itindex{buffer~overrun} \textit{buffer overrun} di un byte.\footnote{uno
-  degli errori più comuni, causato ad esempio dalla scrittura di una stringa
-  di dimensione pari a quella del buffer, in cui ci si dimentica dello zero di
-  terminazione finale.}  In particolare:
+come quello dei \itindex{double~free} \textit{double~free} o i \textit{buffer
+  overrun} di un byte.\footnote{uno degli errori più comuni, causato ad
+  esempio dalla scrittura di una stringa di dimensione pari a quella del
+  buffer, in cui ci si dimentica dello zero di terminazione finale.}  In
+particolare:
 \begin{itemize*}
 \item se la variabile è posta a $0$ gli errori vengono ignorati;
 \item se la variabile è posta a $1$ viene stampato un avviso sullo
@@ -1454,15 +1458,15 @@ selezionare con maggior finezza le pagine da bloccare, ad esempio usando
 \const{MCL\_FUTURE} ci si può limitare a tutte le pagine allocate a partire
 dalla chiamata della funzione.
 
-In ogni caso un processo real-time che deve entrare in una
+In ogni caso un processo \textit{real-time} che deve entrare in una
 \index{sezione~critica} sezione critica deve provvedere a riservare memoria
 sufficiente prima dell'ingresso, per scongiurare l'occorrenza di un eventuale
-\itindex{page~fault} \textit{page fault} causato dal meccanismo di
-\itindex{copy~on~write} \textit{copy on write}.  Infatti se nella
-\index{sezione~critica} sezione critica si va ad utilizzare memoria che non è
-ancora stata riportata in RAM si potrebbe avere un \itindex{page~fault}
-\textit{page fault} durante l'esecuzione della stessa, con conseguente
-rallentamento (probabilmente inaccettabile) dei tempi di esecuzione.
+\textit{page fault} causato dal meccanismo di \itindex{copy~on~write}
+\textit{copy on write}.  Infatti se nella \index{sezione~critica} sezione
+critica si va ad utilizzare memoria che non è ancora stata riportata in RAM si
+potrebbe avere un \textit{page fault} durante l'esecuzione della stessa, con
+conseguente rallentamento (probabilmente inaccettabile) dei tempi di
+esecuzione.
 
 In genere si ovvia a questa problematica chiamando una funzione che ha
 allocato una quantità sufficientemente ampia di \index{variabili!automatiche}
@@ -1570,8 +1574,7 @@ errori di programmazione. Esempi di questi errori sono i \itindex{double~free}
 allocazione,\footnote{entrambe queste operazioni causano in genere la
   corruzione dei dati di controllo delle funzioni di allocazione, che vengono
   anch'essi mantenuti nello \itindex{heap} \textit{heap} per tenere traccia
-  delle zone di memoria allocata.} o i classici \itindex{memory~leak}
-\textit{memory leak}.
+  delle zone di memoria allocata.} o i classici \textit{memory leak}.
 
 Abbiamo visto in sez.~\ref{sec:proc_mem_lock} come una prima funzionalità di
 ausilio nella ricerca di questi errori sia l'uso della variabile di ambiente