X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=process.tex;h=0678e277a3882de71aec3782dddb610eb7f0e72f;hp=087f5fb0fa429740a1f1b25601efcb67e8eeb845;hb=6907e5e6ff5c69a34dc9d3664388cdb9f76ede82;hpb=c09cd30d45162e3248a33baefb7a28feb8e1487a

diff --git a/process.tex b/process.tex
index 087f5fb..0678e27 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",
@@ -173,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.
@@ -185,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
@@ -276,10 +276,13 @@ necessariamente adiacenti).
 Per la gestione da parte del kernel la memoria virtuale viene divisa in pagine
 di dimensione fissa (che ad esempio sono di 4kb su macchine a 32 bit e 8kb
 sulle alpha, valori strettamente connessi all'hardware di gestione della
-memoria), e ciascuna pagina della memoria virtuale è associata ad un supporto
-che può essere una pagina di memoria reale o ad un dispositivo di stoccaggio
-secondario (in genere lo spazio disco riservato alla swap, o i file che
-contengono il codice).
+memoria),\footnote{con le versioni più recenti del kernel è possibile anche
+  utilizzare pagine di dimensioni maggiori, per sistemi con grandi
+  quantitativi di memoria in cui l'uso di pagine troppo piccole comporta una
+  perdita di prestazioni.} e ciascuna pagina della memoria virtuale è
+associata ad un supporto che può essere una pagina di memoria reale o ad un
+dispositivo di stoccaggio secondario (in genere lo spazio disco riservato alla
+swap, o i file che contengono il codice).
 
 Lo stesso pezzo di memoria reale (o di spazio disco) può fare da supporto a
 diverse pagine di memoria virtuale appartenenti a processi diversi (come
@@ -568,7 +571,7 @@ che contiene l'errore. Per questo motivo 
 In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
 programmazione ad oggetti, il problema dei \textit{memory leak} è notevolmente
 ridimensionato attraverso l'uso accurato di appositi oggetti come gli
-\textit{smartpointers}.  Questo però va a scapito delle performance
+\textit{smartpointers}.  Questo però va a scapito delle prestazioni
 dell'applicazione in esecuzione.
 
 In altri linguaggi come il java e recentemente il C\# il problema non si pone
@@ -581,11 +584,11 @@ In tal caso, attraverso meccanismi simili a quelli del \textit{reference
 riferita da nessuna parte del codice in esecuzione, può essere deallocata
 automaticamente in qualunque momento dall'infrastruttura.
 
-Anche questo va a scapito delle performance dell'applicazione in esecuzione
+Anche questo va a scapito delle prestazioni dell'applicazione in esecuzione
 (inoltre le applicazioni sviluppate con tali linguaggi di solito non sono
 eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
 la presenza di una infrastruttura per la loro interpretazione e pertanto hanno
-di per sé delle performance più scadenti rispetto alle stesse applicazioni
+di per sé delle prestazioni più scadenti rispetto alle stesse applicazioni
 compilate direttamente).  Questo comporta però il problema della non
 predicibilità del momento in cui viene deallocata la memoria precedentemente
 allocata da un oggetto.
@@ -1401,7 +1404,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
@@ -1584,13 +1587,13 @@ 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