\param{aiocbp}.
\bodydesc{La funzione restituisce 0 se le operazioni si sono concluse con
- successo, altrimenti restituisce il codice di errore.}
-% }, che viene salvato
-% anche in \var{errno}, i valori possibili sono:
-% \begin{errlist}
-% \item[\macro{ENOSYS}] La funzione non è implementata.
-% \item[\macro{EINPROGRESS}] L'operazione è ancora in corso.
-% \item[\macro{EINVAL}] Si è specificato un valore non valido per i campi
-% \var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}.
-% \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato.
-% \end{errlist}
-% più tutti quelli possibili per le sottostanti operazioni, .}
+ successo, altrimenti restituisce il codice di errore relativo al loro
+ fallimento.}
\end{prototype}
Se l'operazione non si è ancora completata viene restituito l'errore di
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 effettuare
-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:
+ che però è stata dismessa per restare aderenti allo standard.} ha introdotto
+due nuove system call, \func{readv} e \func{writev}, che permettono di
+effettuare 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}
\label{fig:file_iovec}
\end{figure}
-I buffer da utilizzare sono specificati attraverso l'argomento \var{vector} che
-è un vettore di tale strutture, la cui lunghezza è specificata da \param{count}.
-Essi verranno letti (o scritti) nell'ordine in cui li si sono specificati.
-
+I buffer da utilizzare sono indicati attraverso l'argomento \param{vector} che
+è un vettore di strutture \var{iovec}, la cui lunghezza è specificata da
+\param{count}. Ciascuna struttura dovrà essere inizializzata per
+opportunamente per indicare i vari buffer da/verso i quali verrà eseguito il
+trasferimento dei dati. Essi verranno letti (o scritti) nell'ordine in cui li
+si sono specificati nel vattore \var{vector}.
\subsection{File mappati in memoria}
Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
rispetto a quella classica vista in \capref{cha:file_unix_interface}, è il
-cosiddetto \textit{memory-mapped I/O}, che attraverso il meccanismo della
+cosiddetto \textit{memory-mapped I/O}, che, attraverso il meccanismo della
\textsl{paginazione}\index{paginazione} usato dalla memoria virtuale (vedi
-\secref{sec:proc_mem_gen}) permette di \textsl{mappare} il contenuto di un
-file in una sezione dello spazio di indirizzi del processo.
+\secref{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 \figref{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 che trasferirà il contenuto di quel segmento sul file
+invece che nella swap.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=10cm]{img/mmap_layout}
+ \caption{Disposizione della memoria di un processo quando si esegue la
+ mappatuara 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 dalla sezione di memoria; 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
+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, la sezione di memoria mappata su cui si opera sarà a sua volta letta
o scritta sul file una pagina alla volta e solo per le parti effettivamente
-usate, il tutto in maniera completamente trasparente al processo; l'acceso
+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.
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
- mapping}, la prima di queste è \func{mmap}, che esegue la mappatura in
-memoria un file; il suo prototipo è:
+L'interfaccia prevede varie funzioni per la gestione del \textit{memory mapped
+ I/O}, la prima di queste è \func{mmap}, che serve ad eseguire la mappatura
+in memoria di un file; il suo prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/mman.h}
- \funcdecl{void * mmap(void *start, size\_t length, int prot, int flags, int
+ \funcdecl{void * mmap(void * start, size\_t length, int prot, int flags, int
fd, off\_t offset)}
Esegue la mappatura in memoria del file \param{fd}.
\macro{MAP\_EXECUTABLE}& Ignorato. \\
\macro{MAP\_NORESERVE} & Si usa con \macro{MAP\_PRIVATE}. Non riserva
delle pagine di swap ad uso del meccanismo di
- \textit{copy on write} per mantenere le modifiche
- fatte alla regione mappata, in
+ \textit{copy on write} per mantenere le
+ modifiche fatte alla regione mappata, in
questo caso dopo una scrittura, se non c'è più
memoria disponibile, si ha l'emissione di
un \macro{SIGSEGV}. \\
\footnotetext{L'uso di questo flag con \macro{MAP\_SHARED} è
stato implementato in Linux a partire dai kernel della serie 2.4.x.}
-Un file viene sempre mappato su multipli delle dimensioni di una pagina,
-qualora esso sia più corto la parte restante è riempita con zeri; eventuali
-scritture in quella zona di memoria non vengono riportate sul file. Se le
-dimensioni del file cambiano (esso viene esteso o troncato), non è specificato
-quale effetto viene a aversi sulle pagine di memoria che corrispondono alle
-regioni aggiunte o tolte.
+Gli effetti dell'accesso ad una zona di memoria mappata su file possono essere
+piuttosto complessi, essi si possono comprendere solo tenendo presente che
+tutto quanto è comunque basato sul basato sul meccanismo della memoria
+virtuale. Questo comporta allora una serie di conseguenze. La più ovvia è che
+se si cerca di scrivere su una zona mappata in sola lettura si avrà
+l'emissione di un segnale di \macro{SIGSEGV}, dato che i permessi sul segmento
+di memoria relativo non consentono questo tipo di accesso.
+
+È invece assai più complessa la questione relativa agli accessi al di fuori
+della regione di cui si è richiesta la mappatura. In generale infatti si è
+portati a ritenere che anch'essi dovrebbero dar luogo all'emissione di un
+segnale di \macro{SIGSEGV}; questo però non tiene conto del fatto che essendo
+basata sul meccanismo della paginazione, una mappatura non può che essere
+eseguita su un segmento di memoria di dimensioni uguali ad un multiplo di
+quelle di una pagina. In generale dette dimensioni potranno non corrispondere
+alle dimensioni effettive del file o della sezione che si vuole mappare. Il
+caso più comune che si presenta è quello illustrato in
+\figref{fig:file_mmap_boundary}, in cui la sezione di file non rientra nei
+confini di una pagina: in tal caso verrà mappato su un segmento di memoria che
+si estende fino al bordo della pagina successiva.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=10cm]{img/mmap_boundary}
+ \caption{Schema della mappatura in memoria di una sezione di file di
+ dimensioni non corripondenti al bordo di una pagina.}
+ \label{fig:file_mmap_boundary}
+\end{figure}
+
+Si ha così una situazione in cui sarà possibile accedere, senza ottenere un
+\macro{SIGSEGV}, a quella zona di memoria che eccede le dimensioni specificate
+da \param{lenght}, dato che essa è presente nello spazio di indirizzi del
+processo, anche se non è mappata sul file. In questo caso quello che succede è
+che gli accessi in lettura restituiranno dei valori nulli, mentre gli accessi
+in scrittura non avranno alcun effetto e non saranno scritti sul file.
+
+Un caso più complesso è quello illustrato in \figref{fig:file_mmap_exceed},
+che avviene quando le dimensioni del file sono più corte di quelle su cui si
+vuole effettuare la mappatura, oppure quando il file è stato troncato da un
+altro processo ad una dimensione inferiore.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=10cm]{img/mmap_exceed}
+ \caption{Schema della mappatura in memoria di file di dimensioni inferiori
+ alla lunghezza richiesta.}
+ \label{fig:file_mmap_exceed}
+\end{figure}
+
+In tal caso per la parte del file esistente vale esattamente quanto detto in
+precedenza, mentre per la parte di memoria che eccede il bordo della pagina,
+ma inferiore alle dimensioni richiete con \param{length}, si avrà il segnale
+\macro{SIGBUS}.
Si tenga presente che non tutti i file possono venire mappati in memoria, la
mappatura infatti introduce una corrispondenza biunivoca fra una sezione di un
(un esempio è l'interfaccia ponte PCI-VME del chip Universe) di dispositivi
che sono utilizzabili praticamente solo con questa interfaccia.
-Passando attraverso una \func{fork} i file mappati in memoria vengono
-ereditati in maniera trasparente dal processo figlio, mantenendo gli stessi
-attributi avuti nel padre; così se si è usato \macro{MAP\_SHARED} padre e
-figlio accederanno allo stesso file in maniera condivisa, mentre se si è usato
-\macro{MAP\_PRIVATE} ciascuno di essi manterrà una sua versione privata
-indipendente. Non c'è invece nessun passaggio attraverso una \func{exec}, dato
-che quest'ultima sostituisce tutto lo spazio degli indirizzi di un processo
-con quello di un nuovo programma.
+Dato che passando attraverso una \func{fork} lo spazio di indirizzi viene
+copiato, i file mappati in memoria verranno ereditati in maniera trasparente
+dal processo figlio, mantenendo gli stessi attributi avuti nel padre; così se
+si è usato \macro{MAP\_SHARED} padre e figlio accederanno allo stesso file in
+maniera condivisa, mentre se si è usato \macro{MAP\_PRIVATE} ciascuno di essi
+manterrà una sua versione privata indipendente. Non c'è invece nessun
+passaggio attraverso una \func{exec}, dato che quest'ultima sostituisce tutto
+lo spazio degli indirizzi di un processo con quello di un nuovo programma.
Quando si effettua la mappatura di un file vengono pure modificati i tempi ad
esso associati (si ricordi quanto esposto in \secref{sec:file_file_times}). Il
Indicare un intervallo che non contiene pagine mappate non è un errore.
Alla conclusione del processo, ogni pagina mappata verrà automaticamente
-rilasciata, mentre la chiusura del file descriptor non ha alcun effetto sulla
-mappatura della memoria.
+rilasciata, mentre la chiusura del file descriptor usato per effettuare la
+mappatura in memoria non ha alcun effetto sulla stessa.
\section{Il file locking}
projects / gapil.git / blobdiff