Reindicizzate alcune macro, messa sezione sulle opzioni di IP, risistemata
[gapil.git] / fileadv.tex
index def60425b144d29a53afc19206fffbb1968e94d4..9e2bf77df693713c7f845d5b83c00828ddcdf0fa 100644 (file)
@@ -1,6 +1,6 @@
 %% fileadv.tex
 %%
-%% Copyright (C) 2000-2004 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2005 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 "Un preambolo",
@@ -173,7 +173,7 @@ sez.~\ref{sec:TCP_urgent_data}).
 
 Dato che in genere non si tengono mai sotto controllo fino a
 \const{FD\_SETSIZE} file contemporaneamente la funzione richiede di
-specificare qual'è il numero massimo dei file descriptor indicati nei tre
+specificare qual è il numero massimo dei file descriptor indicati nei tre
 insiemi precedenti. Questo viene fatto per efficienza, per evitare di passare
 e far controllare al kernel una quantità di memoria superiore a quella
 necessaria. Questo limite viene indicato tramite l'argomento \param{n}, che
@@ -495,7 +495,7 @@ percentuale) sono diventati attivi.
 
 Tuttavia con l'implementazione classica dei segnali questa modalità di I/O
 presenta notevoli problemi, dato che non è possibile determinare, quando i
-file descriptor sono più di uno, qual'è quello responsabile dell'emissione del
+file descriptor sono più di uno, qual è quello responsabile dell'emissione del
 segnale. Inoltre dato che i segnali normali non si accodano (si ricordi quanto
 illustrato in sez.~\ref{sec:sig_notification}), in presenza di più file
 descriptor attivi contemporaneamente, più segnali emessi nello stesso momento
@@ -740,7 +740,7 @@ compiuta dalla funzione \func{aio\_fsync}, che ha lo stesso effetto della
 analoga \func{fsync}, ma viene eseguita in maniera asincrona; il suo prototipo
 è:
 \begin{prototype}{aio.h}
-{ssize\_t aio\_return(int op, struct aiocb *aiocbp)} 
+{int aio\_fsync(int op, struct aiocb *aiocbp)} 
 
 Richiede la sincronizzazione dei dati per il file indicato da \param{aiocbp}.
   
@@ -982,29 +982,34 @@ rispetto a quella classica vista in cap.~\ref{cha:file_unix_interface}, 
 cosiddetto \textit{memory-mapped I/O}, che, attraverso il meccanismo della
 \textsl{paginazione}\index{paginazione} usato dalla memoria virtuale (vedi
 sez.~\ref{sec:proc_mem_gen}), permette di \textsl{mappare} il contenuto di un
-file in una sezione dello spazio di indirizzi del processo. Il meccanismo è
-illustrato in fig.~\ref{fig:file_mmap_layout}, una sezione del file viene
-riportata direttamente nello spazio degli indirizzi del programma. Tutte le
-operazioni su questa zona verranno riportate indietro sul file dal meccanismo
-della memoria virtuale\index{memoria~virtuale} che trasferirà il contenuto di
-quel segmento sul file invece che nella swap, per cui si può parlare tanto di
-file mappato in memoria, quanto di memoria mappata su file.
+file in una sezione dello spazio di indirizzi del processo. 
+
+Il meccanismo è illustrato in fig.~\ref{fig:file_mmap_layout}, una sezione del
+file viene \textsl{mappata} direttamente nello spazio degli indirizzi del
+programma.  Tutte le operazioni di lettura e scrittura su variabili contenute
+in questa zona di memoria verranno eseguite leggendo e scrivendo dal contenuto
+del file attraverso il sistema della memoria virtuale\index{memoria~virtuale}
+che in maniera analoga a quanto avviene per le pagine che vengono salvate e
+rilette nella swap, si incaricherà di sincronizzare il contenuto di quel
+segmento di memoria con quello del file mappato su di esso.  Per questo motivo
+si può parlare tanto di \textsl{file mappato in memoria}, quanto di
+\textsl{memoria mappata su file}.
 
 \begin{figure}[htb]
   \centering
-  \includegraphics[width=7.cm]{img/mmap_layout}
+  \includegraphics[width=14cm]{img/mmap_layout}
   \caption{Disposizione della memoria di un processo quando si esegue la
   mappatura in memoria di un file.}
   \label{fig:file_mmap_layout}
 \end{figure}
 
-Tutto questo comporta una notevole semplificazione delle operazioni di I/O, in
-quanto non sarà più necessario utilizzare dei buffer intermedi su cui
-appoggiare i dati da traferire, ma questi potranno essere acceduti
-direttamente nella sezione di memoria mappata; inoltre questa interfaccia è
-più efficiente 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.
+L'uso del \textit{memory-mappung} comporta una notevole semplificazione delle
+operazioni di I/O, in quanto non sarà più necessario utilizzare dei buffer
+intermedi su cui appoggiare i dati da traferire, poiché questi potranno essere
+acceduti direttamente nella sezione di memoria mappata; inoltre questa
+interfaccia è più efficiente 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,\index{memoria~virtuale} la sezione di memoria mappata su cui si
@@ -1012,15 +1017,18 @@ opera sar
 per le parti effettivamente usate, il tutto in maniera completamente
 trasparente al processo; l'accesso alle pagine non ancora caricate avverrà
 allo stesso modo con cui vengono caricate in memoria le pagine che sono state
-salvate sullo swap.  Infine 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, e non della memoria su cui possono esserne lette delle porzioni.
-
-L'interfaccia prevede varie funzioni per la gestione del \textit{memory mapped
-  I/O}, la prima di queste è \funcd{mmap}, che serve ad eseguire la mappatura
-in memoria di un file; il suo prototipo è:
+salvate sullo swap.
+
+Infine 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, e non della
+memoria su cui possono esserne lette delle porzioni.
+
+L'interfaccia POSIX implementata da Linux prevede varie funzioni per la
+gestione del \textit{memory mapped I/O}, la prima di queste, che serve ad
+eseguire la mappatura in memoria di un file, è \funcd{mmap}; il suo prototipo
+è:
 \begin{functions}
   
   \headdecl{unistd.h}
@@ -1094,7 +1102,7 @@ specificato come maschera binaria ottenuta dall'OR di uno o pi
 riportati in tab.~\ref{tab:file_mmap_flag}; il valore specificato deve essere
 compatibile con la modalità di accesso con cui si è aperto il file.
 
-L'argomento \param{flags} specifica infine qual'è il tipo di oggetto mappato,
+L'argomento \param{flags} specifica infine qual è il tipo di oggetto mappato,
 le opzioni relative alle modalità con cui è effettuata la mappatura e alle
 modalità con cui le modifiche alla memoria mappata vengono condivise o
 mantenute private al processo che le ha effettuate. Deve essere specificato
@@ -1877,7 +1885,7 @@ POSIX), e la variabile \var{cmd} che specifica la modalit
 lock (bloccante o meno), a seconda dell'opzione \cmd{-b}.
 
 Il programma inizia col controllare (\texttt{\small 11--14}) che venga passato
-un parametro (il file da bloccare), che sia stato scelto (\texttt{\small
+un argomento (il file da bloccare), che sia stato scelto (\texttt{\small
   15--18}) il tipo di lock, dopo di che apre (\texttt{\small 19}) il file,
 uscendo (\texttt{\small 20--23}) in caso di errore. A questo punto il
 comportamento dipende dalla semantica scelta; nel caso sia BSD occorre