Client per il servizio echo su UDP e relative chiacchiere

[gapil.git] / process.tex

diff --git a/process.tex b/process.tex
index 831c6482e8e4b096847d7bf8a392d1b9225cba85..39e01017ab7dcdb361b59780adb902d6d7e9e435 100644 (file)
--- a/process.tex
+++ b/process.tex
@@ -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
@@ -370,7 +373,7 @@ seguenti segmenti:
   puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
     variabili che vanno nel segmento dati, e non è affatto vero in generale.}
    
-  Storicamente questo segmento viene chiamato BBS (da \textit{block started by
+  Storicamente questo segmento viene chiamato BSS (da \textit{block started by
     symbol}). La sua dimensione è fissa.
   
 \item Lo \textit{heap}. Tecnicamente lo si può considerare l'estensione del
@@ -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.
@@ -1503,7 +1506,7 @@ funzione da cui si era partiti, quando serve.  La funzione che permette di
 salvare il contesto dello stack è \funcd{setjmp}, il cui prototipo è:
 \begin{functions}
   \headdecl{setjmp.h}
-  \funcdecl{void setjmp(jmp\_buf env)}
+  \funcdecl{int setjmp(jmp\_buf env)}
   
   Salva il contesto dello stack.