Completato I/O vettorizzato, si comincia il memory mapped.
authorSimone Piccardi <piccardi@gnulinux.it>
Thu, 1 Aug 2002 16:36:41 +0000 (16:36 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Thu, 1 Aug 2002 16:36:41 +0000 (16:36 +0000)
Makefile
fileadv.tex
gapil.tex

index 21ca364..e50363e 100644 (file)
--- a/Makefile
+++ b/Makefile
@@ -1,15 +1,14 @@
-all: html dvi ps pdf img
 
-html:
+html: *.tex
        latex2html -local_icons -no_math -no_footnode gapil.tex
 
-dvi: 
+gapil.dvi:  *.tex
        latex gapil.tex
 
-pdf: 
+gapil.pdf:  *.tex
        pdflatex gapil.tex
 
-ps: 
+gapil.ps: gapil.dvi 
        dvips -o gapil.ps gapil.dvi
 
 install:
index a0c5f05..9adbf64 100644 (file)
@@ -398,7 +398,7 @@ attraverso l'uso di una apposita struttura \type{aiocb} (il cui nome sta per
 tutte le funzioni dell'interfaccia. La sua definizione, come effettuata in
 \file{aio.h}, è riportata in \figref{fig:file_aiocb}. Nello steso file è
 definita la macro \macro{\_POSIX\_ASYNCHRONOUS\_IO}, che dichiara la
-disponibilità di questa funzionalità.
+disponibilità dell'interfaccia per l'I/O asincrono.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -423,17 +423,18 @@ struct aiocb
 \end{figure}
 
 Le operazioni di I/O asincrono possono essere effettuate solo su un file già
-aperto, il cui file descriptor deve essere specificato tramite il campo
-\var{aio\_fildes}; il file deve inoltre supportare la funzione \func{lseek},
+aperto; il file deve inoltre supportare la funzione \func{lseek},
 pertanto terminali e pipe sono esclusi. Non c'è limite al numero di operazioni
 contemporanee effettuabili su un singolo file.
 
-Dato che più operazioni possono essere eseguita in maniera asincrona, il
-concetto di posizione corrente sul file viene a mancare; pertanto ciascuna
-operazione deve sempre specificare nel campo \var{aio\_offset} la posizione
-sul file da cui i dati saranno letti o scritti. Nel campo \var{aio\_buf} poi
-andrà specificato l'indirizzo del buffer usato per l'I/O, ed in
-\var{aio\_nbytes} la lunghezza del trasferimento.
+Ogni operazione deve inizializzare opportunamente un \textit{control block}.
+Il file descriptor su cui operare deve essere specificato tramite il campo
+\var{aio\_fildes}; dato che più operazioni possono essere eseguita in maniera
+asincrona, il concetto di posizione corrente sul file viene a mancare;
+pertanto si deve sempre specificare nel campo \var{aio\_offset} la posizione
+sul file da cui i dati saranno letti o scritti.  Nel campo \var{aio\_buf} deve
+essere specificato l'indirizzo del buffer usato per l'I/O, ed in
+\var{aio\_nbytes} la lunghezza del blocco di dati da trasferire.
 
 Il campo \var{aio\_reqprio} permette di settare la priorità delle operazioni
 di I/O.\footnote{in generale perché ciò sia possibile occorre che la
@@ -443,9 +444,10 @@ di I/O.\footnote{in generale perch
 da quella del processo chiamante (vedi \secref{sec:proc_priority}), cui viene
 sottratto il valore di questo campo.
 
-Il campo \var{aio\_lio\_opcode} è usato dalla funzione \func{lio\_listio}, che
-permette di far partire una serie di operazioni in contemporanea su una lista
-di file. Tramite questo campo si specifica quale è la natura di ciascuna di
+Il campo \var{aio\_lio\_opcode} è usato soltanto dalla funzione
+\func{lio\_listio}, che, come vedremo più avanti, permette di eseguire con una
+sola chiamanta una serie di operazioni, usando un vettore di \textit{control
+  block}. Tramite questo campo si specifica quale è la natura di ciascuna di
 esse.
 
 \begin{figure}[!htb]
@@ -485,10 +487,10 @@ che indica le modalit
   con gli attributi specificati da \var{sigev\_notify\_attribute}.
 \end{basedescript}
 
-Le due funzioni base dell'interfaccia POSIX.1b per l'I/O asincrono sono
-\func{aio\_read} e \func{aio\_write}.  Esse servono a richiedere una lettura
-od una scrittura asincrona di dati usando la struttura \type{aiocb} appena
-descritta; i rispettivi prototipi sono:
+Le due funzioni base dell'interfaccia per l'I/O asincrono sono
+\func{aio\_read} ed \func{aio\_write}.  Esse permettono di richiedere una
+lettura od una scrittura asincrona di dati, usando la struttura \type{aiocb}
+appena descritta; i rispettivi prototipi sono:
 \begin{functions}
   \headdecl{aio.h}
 
@@ -525,18 +527,17 @@ Si tenga inoltre presente che deallocare la memoria indirizzata da
 operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari
 campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la
 richiesta.  Questo comporta che occorre evitare di usare per \param{aiocbp}
-variabili automatiche, effettuando le chiamate all'interno di una subroutine,
-e che non si deve riutilizzare la stessa struttura per un'ulteriore operazione
-fintanto che la precedente non si sia ultimata. In generale per ogni
-operazione di I/O asincrono si deve utilizzare una ed una sola struttura
-\type{aiocb}.
-
-Si ricordi che, operando in modalità asincrona, il successo di queste funzioni
-non implica che le operazioni richieste siano state effettivamente eseguite in
-maniera corretta.  Per verificare l'esito delle operazioni l'interfaccia
-prevede altre due funzioni, che permettono di controllare lo stato di
-esecuzione. La prima è \func{aio\_error}, che serve a determinare un eventuale
-stato di errore; il suo prototipo è:
+variabili automatiche e che non si deve riutilizzare la stessa struttura per
+un'ulteriore operazione fintanto che la precedente non sia stata ultimata. In
+generale per ogni operazione di I/O asincrono si deve utilizzare una diversa
+struttura \type{aiocb}.
+
+Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o
+\func{aio\_write} non implica che le operazioni siano state effettivamente
+eseguite in maniera corretta; per verificarne l'esito l'interfaccia prevede
+altre due funzioni, che permettono di controllare lo stato di esecuzione. La
+prima è \func{aio\_error}, che serve a determinare un eventuale stato di
+errore; il suo prototipo è:
 \begin{prototype}{aio.h}
   {int aio\_error(const struct aiocb *aiocbp)}  
 
@@ -559,19 +560,19 @@ stato di errore; il suo prototipo 
 
 Se l'operazione non si è ancora completata viene restituito l'errore di
 \macro{EINPROGRESS}. La funzione ritorna zero quando l'operazione si è
-conclusa con successo, altrimenti restituisce il codice di errore, ed esegue
-il settaggio di \var{errno}. In caso caso di errore esso può essere sia uno
-dei precedentemente specificati \macro{EINVAL} ed \macro{EBADF}, dovuti ad un
-valore errato per \param{aiocbp} che uno dei possibili errori dovuti alle
-chiamate al sistema sottostanti l'esecuzione dell'operazione di I/O richiesta,
-relativi alle funzioni \func{read}, \func{write} e \func{fsync}.
-
-
-Una volta che si sia certi che le operazioni si siano concluse (cioè dopo che
-una chiamata ad \func{aio\_error} non ha restituito \macro{EINPROGRESS}, si
-può usare la seconda funzione dell'interfaccia, \func{aio\_return}, per
-verificare il completamento delle operazioni di I/O asincrono, il cui
-prototipo è:
+conclusa con successo, altrimenti restituisce il codice dell'errore
+verificatosi, ed esegue il corrispondente settaggio di \var{errno}. Il codice
+può essere sia \macro{EINVAL} ed \macro{EBADF}, dovuti ad un valore errato per
+\param{aiocbp}, che uno degli errori possibili durante l'esecuzione
+dell'operazione di I/O richiesta, nel qual caso saranno restituiti, a seconda
+del caso, i codici di errore delle system call \func{read}, \func{write} e
+\func{fsync}.
+
+Una volta che si sia certi che le operazioni siano state concluse (cioè dopo
+che una chiamata ad \func{aio\_error} non ha restituito \macro{EINPROGRESS},
+si potrà usare la seconda funzione dell'interfaccia, \func{aio\_return}, che
+permette di verificare il completamento delle operazioni di I/O asincrono; il
+suo prototipo è:
 \begin{prototype}{aio.h}
 {ssize\_t aio\_return(const struct aiocb *aiocbp)} 
 
@@ -583,11 +584,12 @@ Recupera il valore dello stato di ritorno delle operazioni di I/O associate a
 \end{prototype}
 
 La funzione deve essere chiamata una sola volte per ciascuna operazione
-asincrona, essa infatti fa sì che il sistema rilasci le risorse associate a
-ciascuna operazione. Per questo motivo occorre chiamare la funzione solo dopo
-che l'operazione cui \param{aiocbp} fa riferimento si è completata. 
+asincrona, essa infatti fa sì che il sistema rilasci le risorse ad essa
+associate. É per questo motivo che occorre chiamare la funzione solo dopo che
+l'operazione cui \param{aiocbp} fa riferimento si è completata. Una chiamata
+precedente il completamento delle operazioni darebbe risultati indeterminati.
 
-La funzione restituisce il valore di ritorno relativa all'operazione eseguita,
+La funzione restituisce il valore di ritorno relativo all'operazione eseguita,
 così come ricavato dalla sottostante system call (il numero di byte letti,
 scritti o il valore di ritorno di \func{fsync}).  É importante chiamare sempre
 questa funzione, altrimenti le risorse disponibili per le operazioni di I/O
@@ -609,14 +611,14 @@ Richiede la sincronizzazione dei dati per il file indicato da \param{aiocbp}.
   \macro{EAGAIN}, \macro{EBADF} o \macro{EINVAL}.}
 \end{prototype}
 
-La funzione richiede la sincronizzazione delle operazioni di I/O, essendo la
-richiesta asincrona, ritornando immediatamente. L'esecuzione effettiva della
-sincronizzazione dovrà essere verificata con \func{aio\_error} e
-\func{aio\_return} come per le operazioni di lettura e scrittura. L'argomento
-\param{op} permette di indicare la modalità di esecuzione, se si specifica il
-valore \macro{O\_DSYNC} le operazioni saranno completate con una chiamata a
-\func{fdatasync}, se si specifica \macro{O\_SYNC} con una chiamata a
-\func{fsync} (vedi \secref{sec:file_sync}).
+La funzione richiede la sincronizzazione delle operazioni di I/O, ritornando
+immediatamente. L'esecuzione effettiva della sincronizzazione dovrà essere
+verificata con \func{aio\_error} e \func{aio\_return} come per le operazioni
+di lettura e scrittura. L'argomento \param{op} permette di indicare la
+modalità di esecuzione, se si specifica il valore \macro{O\_DSYNC} le
+operazioni saranno completate con una chiamata a \func{fdatasync}, se si
+specifica \macro{O\_SYNC} con una chiamata a \func{fsync} (per i dettagli vedi
+\secref{sec:file_sync}).
 
 Il successo della chiamata assicura la sincronizzazione delle operazioni fino
 allora richieste, niente è garantito riguardo la sincronizzazione dei dati
@@ -643,29 +645,35 @@ da \param{aiocbp}.
 
 La funzione permette di cancellare una operazione specifica sul file
 \param{fildes}, o tutte le operazioni pendenti, specificando \macro{NULL} come
-valore di \param{aiocbp}.  Quando una operazione viene cancellata
-\func{aio\_error} riporterà \macro{ECANCELED} come codice di errore, ed il suo
-codice di ritorno sarà -1, inoltre il meccanismo di notifica non verrà
-invocato.
-
-I possibili valori di ritorno di \func{aio\_cancel} sono tre:
-\macro{AIO\_ALLDONE} indica che le operazioni di cui si è richiesta la
-cancellazione sono state già completate, \macro{AIO\_CANCELED} indica che
-tutte le operazioni richieste sono state cancellate, e
-\macro{AIO\_NOTCANCELED} che alcune delle operazioni erano in corso e non sono
-state cancellate.  
-
-In quest'ultimo caso occorre chiamare \func{aio\_error} per determinare quali
-sono le operazioni cancellate. Le operazioni che non sono state cancellate
-proseguono il loro corso normale, compreso quanto relativo al meccanismo di
-notifica del loro avvenuto completamento.
-
-Benché l'I/O asincrono preveda un meccanismo di notifica, che permette di
-bloccare un processo in maniera relativamente semplice fino al completamento
-di una determinata operazione, lo standard fornisce anche una apposita
-funzione, \func{aio\_suspend}, che permette di sospendere l'esecuzione di un
-processo fino al completamento di una specifica operazione; il suo prototipo
-è:
+valore di \param{aiocbp}.  Quando una operazione viene cancellata una
+successiva chiamata ad \func{aio\_error} riporterà \macro{ECANCELED} come
+codice di errore, ed il suo codice di ritorno sarà -1, inoltre il meccanismo
+di notifica non verrà invocato. Se si specifica una operazione relativa ad un
+altro file descriptor il risultato è indeterminato.
+
+In caso di successo, i possibili valori di ritorno per \func{aio\_cancel} sono
+tre (anch'essi definiti in \file{aio.h}):
+\begin{basedescript}{\desclabelwidth{3.0cm}}
+\item[\macro{AIO\_ALLDONE}] indica che le operazioni di cui si è richiesta la
+  cancellazione sono state già completate,
+  
+\item[\macro{AIO\_CANCELED}] indica che tutte le operazioni richieste sono
+  state cancellate,  
+  
+\item[\macro{AIO\_NOTCANCELED}] indica che alcune delle operazioni erano in
+  corso e non sono state cancellate.
+\end{basedescript}
+
+Nel caso si abbia \macro{AIO\_NOTCANCELED} occorrerà chiamare
+\func{aio\_error} per determinare quali sono le operazioni effettivamente
+cancellate. Le operazioni che non sono state cancellate proseguiranno il loro
+corso normale, compreso quanto richiesto riguardo al meccanismo di notifica
+del loro avvenuto completamento.
+
+Benché l'I/O asincrono preveda un meccanismo di notifica, l'interfaccia
+fornisce anche una apposita funzione, \func{aio\_suspend}, che permette di
+sospendere l'esecuzione del processo chiamante fino al completamento di una
+specifica operazione; il suo prototipo è:
 \begin{prototype}{aio.h}
 {int aio\_suspend(const struct aiocb * const list[], int nent, const struct
     timespec *timeout)}
@@ -685,20 +693,19 @@ processo fino al completamento di una specifica operazione; il suo prototipo
   }
 \end{prototype}
 
-La funzione permette di bloccare il processo chiamante fintanto che almeno una
-delle \param{nent} operazioni specificate nella lista \param{list} è
-completata, per un tempo massimo specificato da \param{timout}, o fintanto che
-non arrivi un segnale.\footnote{si tenga conto che questo segnale può anche
-  essere quello utilizzato come meccanismo di notifica.} La lista deve essere
-inizializzata con delle strutture \var{aiocb} relative ad operazioni
-effettivamente richieste, ma può contenere puntatori nulli, che saranno
-ignorati. In caso si siano specificati valori non validi l'effetto è
-indefinito.  Un valore \macro{NULL} per \param{timout} comporta una attesa
-infinita.
-
-Lo standard infine ha previsto pure una funzione, \func{lio\_listio}, che
-permette di effettuare la richiesta di una intera lista di operazioni di
-lettura o scrittura; il suo prototipo è: 
+La funzione permette di bloccare il processo fintanto che almeno una delle
+\param{nent} operazioni specificate nella lista \param{list} è completata, per
+un tempo massimo specificato da \param{timout}, o fintanto che non arrivi un
+segnale.\footnote{si tenga conto che questo segnale può anche essere quello
+  utilizzato come meccanismo di notifica.} La lista deve essere inizializzata
+con delle strutture \var{aiocb} relative ad operazioni effettivamente
+richieste, ma può contenere puntatori nulli, che saranno ignorati. In caso si
+siano specificati valori non validi l'effetto è indefinito.  Un valore
+\macro{NULL} per \param{timout} comporta l'assenza di timeout.
+
+Lo standard POSIX.1b infine ha previsto pure una funzione, \func{lio\_listio},
+che permette di effettuare la richiesta di una intera lista di operazioni di
+lettura o scrittura; il suo prototipo è:
 \begin{prototype}{aio.h}
   {int lio\_listio(int mode, struct aiocb * const list[], int nent, struct
     sigevent *sig)}
@@ -718,36 +725,104 @@ lettura o scrittura; il suo prototipo 
 \end{prototype}
 
 La funzione esegue la richiesta delle \param{nent} operazioni indicate dalla
-lista \param{list}; questa deve contenere gli indirizzi di altrettanti control
-block, opportunamente inizializzati; in particolare nel caso dovrà essere
-specificato il tipo di operazione tramite il campo \var{aio\_lio\_opcode}, che
-può prendere i tre valori:
-\begin{description*}
-\item[\macro{LIO\_READ}]  richiede una operazione di lettura.
-\item[\macro{LIO\_WRITE}] richiede una operazione di scrittura.
-\item[\macro{LIO\_NOP}] non effettua nessuna operazione.
-\end{description*}
-l'ultimo viene usato quando si ha a che fare con un vettore di dimensione
-fissa, per poter specificare solo alcune operazioni, o quando si è dovuto
-cancellare delle operazioni e si deve ripetere la richiesta per quelle non
-completate.
+lista \param{list}; questa deve contenere gli indirizzi di altrettanti
+\textit{control block}, opportunamente inizializzati; in particolare nel caso
+dovrà essere specificato il tipo di operazione tramite il campo
+\var{aio\_lio\_opcode}, che può prendere i tre valori:
+\begin{basedescript}{\desclabelwidth{2.0cm}}
+\item[\macro{LIO\_READ}]  si richiede una operazione di lettura.
+\item[\macro{LIO\_WRITE}] si richiede una operazione di scrittura.
+\item[\macro{LIO\_NOP}] non si effettua nessuna operazione.
+\end{basedescript}
+l'ultimo valore viene usato quando si ha a che fare con un vettore di
+dimensione fissa, per poter specificare solo alcune operazioni, o quando si è
+dovuto cancellare delle operazioni e si deve ripetere la richiesta per quelle
+non completate.
 
 L'argomento \param{mode} permette di stabilire il comportamento della
 funzione, se viene specificato il valore \macro{LIO\_WAIT} la funzione si
 blocca fino al completamento di tutte le operazioni richieste; se invece si
 spercifica \macro{LIO\_NOWAIT} la funzione ritorna immediatamente dopo aver
 messo in coda tutte le richieste. In questo caso il chiamante può richiedere
-una notifica del completamento di tutte le richieste settando \param{sig}. 
-
+la notifica del completamento di tutte le richieste, settando l'argomento
+\param{sig} in maniera analoga a come si fa per il campo \var{aio\_sigevent}
+di \type{aiocb}.
 
 
 
-\subsection{I/O multiplo}
+\subsection{I/O vettorizzato}
 \label{sec:file_multiple_io}
 
-Un caso abbastanza comune è quello in cui ci si trova a dover affrontare una
+Un caso abbastanza comune è quello in cui ci si trova a dover eseguire una
 serie multipla di operazioni di I/O, come una serie di letture o scritture di
-vari buffer. In questo caso
+vari buffer. Un esempio tipico è quando i dati sono strutturati nei campi di
+una struttura ed essi devono essere caricati o salvati su un file.  Benché
+l'operazione sia facilmente eseguibile attraverso una serie multipla di
+chiamate, ci sono casi in cui si vuole poter contare sulla atomicità delle
+operazioni.
+
+Per questo motivo BSD 4.2\footnote{Le due funzioni sono riprese da BSD4.4 ed
+  integrate anche dallo standard Unix 98; fino alle libc5 Linux usava
+  \type{size\_t} come tipo dell'argomento \param{count}, una scelta logica,
+  che è stata dismessa per restare aderenti allo standard.} ha introdotto due
+nuove system call, \func{readv} e \func{writev}, che permettono di effettare
+con una sola chiamata una lettura o una scrittura su una serie di buffer
+(quello che viene chiamato \textsl{I/O vettorizzato}. I relativi prototipi
+sono:
+\begin{functions}
+  \headdecl{sys/uio.h}
+  
+  \funcdecl{int readv(int fd, const struct iovec *vector, int count)} Esegue
+  una lettura vettorizzata da \param{fd} nei \param{count} buffer specificati
+  da \param{vector}.
+  
+  \funcdecl{int writev(int fd, const struct iovec *vector, int count)} Esegue
+  una scrittura vettorizzata da \param{fd} nei \param{count} buffer
+  specificati da \param{vector}.
+  
+  \bodydesc{Le funzioni restituiscono il numero di byte letti o scritti in
+    caso di successo, e -1 in caso di errore, nel qual caso \var{errno} viene
+    settata ai valori:
+  \begin{errlist}
+  \item[\macro{EBADF}] si è specificato un file descriptor sbagliato.
+  \item[\macro{EINVAL}] si è specificato un valore non valido per uno degli
+    argomenti (ad esempio \param{count} è maggiore di \macro{MAX\_IOVEC}).
+  \item[\macro{EINTR}] la funzione è stata interrotta da un segnale prima di
+    di avere eseguito una qualunque lettura o scrittura.
+  \item[\macro{EAGAIN}] \param{fd} è stato aperto in modalità non bloccante e
+  non ci sono dati in lettura.
+  \item[\macro{EOPNOTSUPP}] La coda delle richieste è momentaneamente piena.
+  \end{errlist}
+  ed inoltre \macro{EISDIR}, \macro{ENOMEM}, \macro{EFAULT} (se non sono stato
+  allocati correttamente i buffer specificati nei campi \func{iov\_base}), più
+  tutti gli ulteriori errori che potrebbero avere le usuali funzioni di
+  lettura e scrittura eseguite su \param{fd}.}
+\end{functions}
+
+Entrambe le funzioni usano una struttura \type{iovec}, definita in
+\figref{fig:file_iovec}, che definisce dove i dati devono essere letti o
+scritti. Il primo campo, \var{iov\_base}, contiene l'indirizzo del buffer ed
+il secondo, \var{iov\_len}, la dimensione dello stesso. 
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+struct iovec {
+    __ptr_t iov_base;    /* Starting address */
+    size_t iov_len;      /* Length in bytes  */
+};
+    \end{lstlisting}
+  \end{minipage} 
+  \normalsize 
+  \caption{La struttura \type{iovec}, usata dalle operazioni di I/O
+    vettorizzato.} 
+  \label{fig:file_iovec}
+\end{figure}
+
+I buffer da utlizzare sono specificati attraverso l'argomento \var{vector} che
+è un array di tale strutture, la cui lunghezza è specificata da \param{count}.
+Essi verranno letti (o scritti) nell'ordine in cui li si sono specificati.
 
 
 
@@ -758,10 +833,27 @@ Una modalit
 rispetto a quella classica, è quella dei file \textsl{mappati in memoria}. In
 sostanza quello che si fa è usare il meccanismo della
 \textsl{paginazione}\index{paginazione} usato per la memoria virtuale (vedi
-\secref{sec:proc_mem_gen}) per trasformare vedere il file in una sezione dello
-spazio di indirizzi del processo, in modo che l'accesso a quest'ultimo con le
-normali operazioni di lettura e scrittura delle variabili in memoria, si
-trasformi in I/O sul file stesso.
+\secref{sec:proc_mem_gen}) vedere il file in una sezione dello spazio di
+indirizzi del processo, in modo che l'accesso a quest'ultimo avvenga con le
+normali operazioni di lettura e scrittura delle variabili in memoria.
+
+Questa interfaccia è più efficiente dell'uso delle usuali funzioni di I/O, in
+quanto permette di caricare in memoria solo le parti del file che sono
+effettivamente usate ad un dato istante. Infatti, dato che l'accesso è fatto
+direttamente attraverso la memoria virtuale, non è necessario trasferire in un
+buffer tutti i dati che potrebbero servire, e poi riscrivere il tutto una
+volta completate le operazioni, la scrittura e la lettura avverranno invece
+direttamente sulla sezione di memoria mappata, che sarà a sua volta letta o
+scritta sul file, una pagina alla volta (e solo per le parti effettivamente
+usate) in maniera trasparente attraverso il meccanismo della paginazione.
+L'acceso alle pagine non ancora caricate avverrà allo stesso modo con cui
+vengono caricate in memoria le pagine che sono state salvate sullo swap.
+
+Inoltre in situazioni in cui la memoria è scarsa, le pagine che mappano un
+file vengono salvate automaticamente, così come le pagine dei programmi
+vengono scritte sulla swap; questo consente di accedere ai file su dimensioni
+il cui solo limite è quello dello spazio di indirizzi disponibile, 
+
 
 
 
index 2eeaa99..be7b703 100644 (file)
--- a/gapil.tex
+++ b/gapil.tex
@@ -74,7 +74,6 @@
 \clearemptydoublepage
 
 %\include{compatib}    % commentare per la stampa PS e PDF
-
 \include{macro}
 \setcounter{secnumdepth}{-2}
 \include{pref}