\bodydesc{La funzione in caso di successo restituisce il numero di file
descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual
- caso \var{errno} viene settata ai valori:
+ caso \var{errno} viene impostata ai valori:
\begin{errlist}
\item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno
degli insiemi.
Infine l'argomento \param{timeout}, specifica un tempo massimo di
attesa\footnote{il tempo è valutato come \textit{elapsed time}.} prima che la
-funzione ritorni; se settato a \macro{NULL} la funzione attende
+funzione ritorni; se impostato a \macro{NULL} la funzione attende
indefinitamente. Si può specificare anche un tempo nullo (cioè una \var{struct
- timeval} con i campi settati a zero), qualora si voglia semplicemente
+ timeval} con i campi impostati a zero), qualora si voglia semplicemente
controllare lo stato corrente dei file descriptor.
La funzione restituisce il totale dei file descriptor pronti nei tre insiemi,
\macro{FD\_ISSET}. In caso di errore la funzione restituisce -1 e gli insiemi
non vengono toccati.
-In Linux \func{select} modifica anche il valore di \param{timeout}, settandolo
-al tempo restante; questo è utile quando la funzione viene interrotta da un
-segnale, in tal caso infatti si ha un errore di \macro{EINTR}, ed occorre
-rilanciare la funzione; in questo modo non è necessario ricalcolare tutte le
-volte il tempo rimanente.\footnote{questo può causare problemi di portabilità
- sia quando si trasporta codice scritto su Linux che legge questo valore, sia
- quando si usano programmi scritti per altri sistemi che non dispongono di
- questa caratteristica e ricalcolano \param{timeout} tutte le volte. In
- genere la caratteristica è disponibile nei sistemi che derivano da System V
- e non disponibile per quelli che derivano da BSD.}
+In Linux \func{select} modifica anche il valore di \param{timeout},
+impostandolo al tempo restante; questo è utile quando la funzione viene
+interrotta da un segnale, in tal caso infatti si ha un errore di
+\macro{EINTR}, ed occorre rilanciare la funzione; in questo modo non è
+necessario ricalcolare tutte le volte il tempo rimanente.\footnote{questo può
+ causare problemi di portabilità sia quando si trasporta codice scritto su
+ Linux che legge questo valore, sia quando si usano programmi scritti per
+ altri sistemi che non dispongono di questa caratteristica e ricalcolano
+ \param{timeout} tutte le volte. In genere la caratteristica è disponibile
+ nei sistemi che derivano da System V e non disponibile per quelli che
+ derivano da BSD.}
Come accennato l'interfaccia di \func{select} è una estensione di BSD; anche
System V ha introdotto una sua interfaccia per gestire l'\textit{I/O
\bodydesc{La funzione restituisce il numero di file descriptor con attività in
caso di successo, o 0 se c'è stato un timeout; in caso di errore viene
- restituito -1 ed \var{errno} viene settata ai valori:
+ restituito -1 ed \var{errno} viene impostata ai valori:
\begin{errlist}
\item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno
degli insiemi.
\end{table}
La funzione ritorna, restituendo il numero di file per i quali si è verificata
-una delle condizioni di attesa richieste o un errore. Lo stato dei file
+una delle condizioni di attesa richieste od un errore. Lo stato dei file
all'uscita della funzione viene restituito nel campo \var{revents} della
-relativa struttura \type{pollfd}, che viene settato alla maschera binaria dei
-valori riportati in \tabref{tab:file_pollfd_flags}, ed oltre alle tre
+relativa struttura \type{pollfd}, che viene impostato alla maschera binaria
+dei valori riportati in \tabref{tab:file_pollfd_flags}, ed oltre alle tre
condizioni specificate tramite \var{events} può riportare anche l'occorrere di
una condizione di errore.
\bodydesc{La funzione in caso di successo restituisce il numero di file
descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual
- caso \var{errno} viene settata ai valori:
+ caso \var{errno} viene impostata ai valori:
\begin{errlist}
\item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno
degli insiemi.
race condition\footnote{in Linux però, non esistendo una system call apposita,
la funzione è implementata nelle \acr{glibc} usando \func{select}, e la
possibilità di una race condition resta.} quando si deve eseguire un test su
-una variabile settata da un manipolatore sulla base dell'occorrenza di un
+una variabile assegnata da un manipolatore sulla base dell'occorrenza di un
segnale per decidere se lanciare \func{select}. Fra il test e l'esecuzione è
presente una finestra in cui potrebbe arrivare il segnale che non sarebbe
rilevato; la race condition diventa superabile disabilitando il segnale prima
del flag \macro{O\_ASYNC},\footnote{l'uso del flag di \macro{O\_ASYNC} e dei
comandi \macro{F\_SETOWN} e \macro{F\_GETOWN} per \func{fcntl} è specifico
di Linux e BSD.} aprire un file in modalità asincrona, così come è possibile
-attivare in un secondo tempo questa modalità settando questo flag attraverso
+attivare in un secondo tempo questa modalità impostando questo flag attraverso
l'uso di \func{fcntl} con il comando \macro{F\_SETFL} (vedi
-\secref{sec:file_fcntl}).
+\secref{sec:file_fcntl}).
In realtà in questo caso non si tratta di I/O asincrono vero e proprio, quanto
di un meccanismo asincrono di notifica delle variazione dello stato del file
\secref{sec:sig_sigaction}).
Per far questo però occorre utilizzare le funzionalità dei segnali real-time
-(vedi \secref{sec:sig_real_time}) settando esplicitamente con il comando
+(vedi \secref{sec:sig_real_time}) imopstando esplicitamente con il comando
\macro{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di
-I/O asincrono (il segnale di default è \macro{SIGIO}). In questo caso il
+I/O asincrono (il segnale predefinito è \macro{SIGIO}). In questo caso il
manipolatore tutte le volte che riceverà \macro{SI\_SIGIO} come valore del
campo \var{si\_code}\footnote{il valore resta \macro{SI\_SIGIO} qualunque sia
il segnale che si è associato all'I/O asincrono, ed indica appunto che il
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
\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
+Il campo \var{aio\_reqprio} permette di impostare la priorità delle operazioni
di I/O.\footnote{in generale perché ciò sia possibile occorre che la
piattaforma supporti questa caratteristica, questo viene indicato definendo
le macro \macro{\_POSIX\_PRIORITIZED\_IO}, e
- \macro{\_POSIX\_PRIORITY\_SCHEDULING}.} La priorità viene settata a partire
-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
+ \macro{\_POSIX\_PRIORITY\_SCHEDULING}.} La priorità viene impostata a
+partire 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 soltanto dalla funzione
+\func{lio\_listio}, che, come vedremo più avanti, permette di eseguire con una
+sola chiamata 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]
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \type{sigevent}, usata per specificare le modailtà di
+ \caption{La struttura \type{sigevent}, usata per specificare le modalità di
notifica degli eventi relativi alle operazioni di I/O asincrono.}
\label{fig:file_sigevent}
\end{figure}
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}
\param{aiocbp}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo, e -1 in caso di
- errore, nel qual caso \var{errno} viene settata ai valori:
+ errore, nel qual caso \var{errno} viene impostata ai valori:
\begin{errlist}
\item[\macro{EBADF}] Si è specificato un file descriptor sbagliato.
\item[\macro{ENOSYS}] La funzione non è implementata.
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)}
\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
\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 la corrispondente impostazione 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)}
\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
esaurimento.
Oltre alle operazioni di lettura e scrittura l'interfaccia POSIX.1b mette a
-disposizione un'altra operazione, quella di sincronizzazione delll'I/O, essa è
+disposizione un'altra operazione, quella di sincronizzazione dell'I/O, essa è
compiuta dalla funzione \func{aio\_fsync}, che ha lo stesso effetto della
-analoga \func{fsync}, ma viene esguita in maniera asincrona; il suo prototipo
+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)}
\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
operazioni di sincronizzazione dei dati saranno completate.
In alcuni casi può essere necessario interrompere le operazioni (in genere
-quando viene richiesta un'uscita immediata dal programam), per questo lo
+quando viene richiesta un'uscita immediata dal programma), per questo lo
standard POSIX.1b prevede una funzioni apposita, \func{aio\_cancel}, che
permette di cancellare una operazione richiesta in precedenza; il suo
prototipo è:
\bodydesc{La funzione restituisce il risultato dell'operazione con un codice
di positivo, e -1 in caso di errore, che avviene qualora si sia specificato
- un valore non valido di \param{fildes}, setta \var{errno} al valore
+ un valore non valido di \param{fildes}, imposta \var{errno} al valore
\macro{EBADF}.}
\end{prototype}
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)}
operazioni specificate da \param{list}.
\bodydesc{La funzione restituisce 0 se una (o più) operazioni sono state
- completate, e -1 in caso di errorem nel qual caso \var{errno} viene
- settata ai valori:
+ completate, e -1 in caso di errore nel qual caso \var{errno} viene
+ impostata ai valori:
\begin{errlist}
\item[\macro{EAGAIN}] Nessuna operazione è stata completata entro
\param{timeout}.
}
\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)}
secondo la modalità \param{mode}.
\bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
- errorem nel qual caso \var{errno} viene settata ai valori:
+ errore, nel qual caso \var{errno} viene impostata ai valori:
\begin{errlist}
\item[\macro{EAGAIN}] Nessuna operazione è stata completata entro
\param{timeout}.
\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
+specifica \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, impostando 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 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}
+
+ \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
+ impostata 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 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}
\label{sec:file_memory_map}
Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
-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.
+rispetto a quella classica vista in \capref{cha:file_unix_interface}, è il
+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. 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 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'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 è \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
+ fd, off\_t offset)}
+
+ Esegue la mappatura in memoria del file \param{fd}.
+
+ \bodydesc{La funzione restituisce il puntatore alla zona di memoria mappata
+ in caso di successo, e \macro{MAP\_FAILED} (-1) in caso di errore, nel
+ qual caso \var{errno} viene impostata ai valori:
+ \begin{errlist}
+ \item[\macro{EBADF}] Il file descriptor non è valido, e non si è usato
+ \macro{MAP\_ANONYMOUS}.
+ \item[\macro{EACCES}] Il file descriptor non si riferisce ad un file
+ regolare, o si è richiesto \macro{MAP\_PRIVATE} ma \param{fd} non è
+ aperto in lettura, o si è richiesto \macro{MAP\_SHARED} e impostato
+ \macro{PROT\_WRITE} ed \param{fd} non è aperto in lettura/scrittura, o
+ si è impostato \macro{PROT\_WRITE} ed \param{fd} è in
+ \textit{append-only}.
+ \item[\macro{EINVAL}] I valori di \param{start}, \param{length} o
+ \param{offset} non sono validi (o troppo grandi o non allineati sulla
+ dimensione delle pagine).
+ \item[\macro{ETXTBSY}] Si è impostato \macro{MAP\_DENYWRITE} ma \param{fd}
+ è aperto in scrittura.
+ \item[\macro{EAGAIN}] Il file è bloccato, o si è bloccata troppa memoria.
+ \item[\macro{ENOMEM}] Non c'è memoria o si è superato il limite sul numero
+ di mappature possibili.
+ \item[\macro{ENODEV}] Il filesystem di \param{fd} no supporta il memory
+ mapping.
+ \end{errlist}
+ }
+\end{functions}
+
+La funzione richiede di mappare in memoria la sezione del file \param{fd} a
+partire da \param{offset} per \param{lenght} byte, preferibilmente
+all'indirizzo \param{start}. Il valore di \param{offset} deve essere un
+multiplo della dimensione di una pagina di memoria. Il valore dell'argomento
+\param{prot} indica la protezione\footnote{in Linux la memoria reale è divisa
+ in pagine: ogni processo vede la sua memoria attraverso uno o più segmenti
+ lineari di memoria virtuale. Per ciascuno di questi segmenti il kernel
+ mantiene nella \textit{page table} la mappatura sulle pagine di memoria
+ reale, ed le modalità di accesso (lettura, esecuzione, scrittura); una loro
+ violazione causa quella che si chiama una \textit{segment violation}, e la
+ relativa emissione del segnale \macro{SIGSEGV}.} da applicare al segmento di
+memoria e deve essere specificato come maschera binaria ottenuta dall'OR di
+uno o più dei valori riportati in \tabref{tab:file_mmap_flag}; il valore
+specificato deve essere compatibile con la modalità con cui si è aperto il
+file.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \macro{PROT\_EXEC} & Le pagine possono essere eseguite.\\
+ \macro{PROT\_READ} & Le pagine possono essere lette.\\
+ \macro{PROT\_WRITE} & Le pagine possono essere scritte.\\
+ \macro{PROT\_NONE} & L'accesso alle pagine è vietato.\\
+ \hline
+ \end{tabular}
+ \caption{Valori dell'argomento \param{prot} di \func{mmap}, relativi alla
+ protezione applicate alle pagine del file mappate in memoria.}
+ \label{tab:file_mmap_prot}
+\end{table}
+L'argomento \param{flags} specifica 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
+come maschera binaria ottenuta dall'OR di uno o più dei valori riportati in
+\tabref{tab:file_mmap_flag}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{10cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \macro{MAP\_FIXED} & Non permette di restituire un indirizzo diverso
+ da \param{start}, se questo non può essere usato
+ \func{mmap} fallisce. Se si imposta questo flag il
+ valore di \param{start} deve essere allineato
+ alle dimensioni di una pagina. \\
+ \macro{MAP\_SHARED} & I cambiamenti sulla memoria mappata vengono
+ riportati sul file e saranno immediatamente
+ visibili agli altri processi che mappano lo stesso
+ file.\footnotemark Il file su disco però non sarà
+ aggiornato fino alla chiamata di \func{msync} o
+ \func{unmap}), e solo allora le modifiche saranno
+ visibili per l'I/O convenzionale. Incompatibile
+ con \macro{MAP\_PRIVATE}. \\
+ \macro{MAP\_PRIVATE} & I cambiamenti sulla memoria mappata non vengono
+ riportati sul file. Ne viene fatta una copia
+ privata cui solo il processo chiamante ha
+ accesso. Le modifiche sono mantenute attraverso
+ il meccanismo del \textit{copy on write} e
+ salvate su swap in caso di necessità. Non è
+ specificato se i cambiamenti sul file originale
+ vengano riportati sulla regione
+ mappata. Incompatibile con \macro{MAP\_SHARED}. \\
+ \macro{MAP\_DENYWRITE} & In Linux viene ignorato per evitare
+ \textit{DoS}\index{DoS} (veniva usato per
+ segnalare che tentativi di scrittura sul file
+ dovevano fallire con \macro{ETXTBUSY}).\\
+ \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
+ questo caso dopo una scrittura, se non c'è più
+ memoria disponibile, si ha l'emissione di
+ un \macro{SIGSEGV}. \\
+ \macro{MAP\_LOCKED} & Se impostato impedisce lo swapping delle pagine
+ mappate. \\
+ \macro{MAP\_GROWSDOWN} & Usato per gli stack. Indica
+ che la mappatura deve essere effettuata con gli
+ indirizzi crecenti verso il basso.\\
+ \macro{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli
+ argomenti \param{fd} e \param{offset} sono
+ ignorati.\footnotemark\\
+ \macro{MAP\_ANON} & Sinonimo di \macro{MAP\_ANONYMOUS}, deprecato.\\
+ \macro{MAP\_FILE} & Valore di compatibiità, deprecato.\\
+ \hline
+ \end{tabular}
+ \caption{Valori possibili dell'argomento \param{flag} di \func{mmap}.}
+ \label{tab:file_mmap_flag}
+\end{table}
+
+\footnotetext{Dato che tutti faranno riferimento alle stesse pagine di
+ memoria.}
+\footnotetext{L'uso di questo flag con \macro{MAP\_SHARED} è
+ stato implementato in Linux a partire dai kernel della serie 2.4.x.}
+
+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
+file ed una sezione di memoria, pertanto si può parlare tanto di file mappato
+in memoria, quanto di memoria mappata su file. Questo comporta che ad esempio
+non è possibile mappare in memoria pipe, socket e fifo, per le quali non ha
+senso parlare di \textsl{sezione}. Lo stesso vale anche per alcuni file di
+dispositivo, che non dispongono della relativa operazione \var{mmap} (si
+ricordi quanto esposto in \secref{sec:file_vfs_work}), ma esistono anche casi
+(un esempio è l'interfaccia ponte PCI-VME del chip Universe) di dispositivi
+che sono utilizzabili praticamente solo con questa interfaccia.
+
+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
+valore di \var{st\_atime} può venir cambiato in qualunque istante a partire
+dal momento in cui la mappatura è stata effettuata: il primo riferimento ad
+una pagina mappata su un file aggiorna questo tempo. I valori di
+\var{st\_ctime} e \var{st\_mtime} possono venir cambiati solo quando si è
+consentita la scrittura sul file (cioè per un file mappato con
+\macro{PROT\_WRITE} e \macro{MAP\_SHARED}) e sono aggiornati dopo la scrittura
+o in corrispondenza di una eventuale \func{msync}.
+
+Dato per i file mappati in memoria le operazioni di I/O sono gestite
+direttamente dalla memoria virtuale, occorre essere consapevoli delle
+interazioni che possono esserci con operazioni effettuate con l'interfaccia
+standard dei file di \capref{sec:file_unix_interface}. Il problema è che una
+volta che si è mappato un file, le operazioni di lettura e scrittura saranno
+eseguite sulla memoria, e riportate su disco in maniera autonoma dal sistema
+della memoria virtuale.
+
+Pertanto se si modifica un file con l'interfaccia standard queste modifiche
+potranno essere visibili o meno a seconda del momento in cui la memoria
+virtuale leggerà dal disco in memoria quella sezione del file, perciò è del
+tutto indefinito il risultato della modifica nei confronti del contenuto della
+memoria mappata.
+
+Se è, per quanto appena visto, sconsigliabile eseguire scritture su file
+attraverso l'interfaccia standard quando lo si è mappato in memoria, è invece
+possibile usare l'interfaccia standard per leggere un file mappato in memoria,
+purché si abbia una certa cura; infatti l'interfaccia dell'I/O mappato in
+memoria mette a disposizione la funzione \func{msync} per sincronizzare il
+contenuto della memoria mappata con il file su disco; il suo prototipo è:
+\begin{functions}
+ \headdecl{unistd.h}
+ \headdecl{sys/mman.h}
+
+ \funcdecl{int msync(const void *start, size\_t length, int flags)}
+
+ Sincronizza i contenuti di una sezione di un file mappato in memoria.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
+ errore nel qual caso \var{errno} viene impostata ai valori:
+ \begin{errlist}
+ \item[\macro{EINVAL}] O \param{start} non è multiplo di \macro{PAGESIZE},
+ o si è specificato un valore non valido per \param{flags}.
+ \item[\macro{EFAULT}] L'intervallo specificato non ricade in una zona
+ precedentemente mappata.
+ \end{errlist}
+ }
+\end{functions}
+
+La funzione esegue la sincronizzazione di quanto scritto nella sezione di
+memoria indicata da \param{start} e \param{offset}, scrivendo le modifiche sul
+file (qualora questo non sia già stato fatto). Provvede anche ad aggiornare i
+relativi tempi di modifica. In questo modo si è sicuri che dopo l'esecuzione
+di \func{msync} le funzioni dell'interfaccia standard troveranno un contenuto
+del file aggiornato.
+
+L'argomento \param{flag} è specificato come maschera binaria composta da un OR
+dei valori riportati in \tabref{tab:file_mmap_rsync}, di questi però
+\macro{MS\_ASYNC} e \macro{MS\_SYNC} sono incompatibili; con il primo valore
+infatti la funzione si limita ad inoltrare la richiesta di sincronizzazione al
+meccanismo della memoria virtuale, ritornando subito, mentre con il secondo
+attende che la sincronizzazione sia stata effettivamente eseguita. Il terzo
+flag fa invalidare le pagine di cui si richiede la sincronizzazione per tutte
+le mappature dello stesso file, così che esse possano essere immediatamente
+aggiornate ai nuovi valori.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \macro{MS\_ASYNC} & Richiede la sincronizzazione.\\
+ \macro{MS\_SYNC} & Attende che la sincronizzazione si eseguita.\\
+ \macro{MS\_INVALIDATE}& Richiede che le altre mappature dello stesso file
+ siano invalidate.\\
+ \hline
+ \end{tabular}
+ \caption{Valori dell'argomento \param{flag} di \func{msync}.}
+ \label{tab:file_mmap_rsync}
+\end{table}
+
+Una volta che si sono completate le operazioni di I/O si può eliminare la
+mappatura della memoria usando la funzione \func{munmap}, il suo prototipo è:
+\begin{functions}
+ \headdecl{unistd.h}
+ \headdecl{sys/mman.h}
+
+ \funcdecl{int munmap(void *start, size\_t length)}
+
+ Rilascia la mappatura sulla sezione di memoria specificata.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
+ errore nel qual caso \var{errno} viene impostata ai valori:
+ \begin{errlist}
+ \item[\macro{EINVAL}] L'intervallo specificato non ricade in una zona
+ precedentemente mappata.
+ \end{errlist}
+ }
+\end{functions}
+
+La funzione cancella la mappatura per l'intervallo specificato attraverso
+\param{start} e \param{length}, ed ogni successivo accesso a tale regione
+causerà un errore di accesso in memoria. L'argomento \param{start} deve essere
+allineato alle dimensioni di una pagina di memoria, e la mappatura di tutte le
+pagine contenute (anche parzialmente) nell'intervallo indicato, verrà rimossa.
+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 usato per effettuare la
+mappatura in memoria non ha alcun effetto sulla stessa.
\section{Il file locking}
\subsection{Il \textit{mandatory locking}}
\label{sec:file_mand_locking}
-Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4,
-
-
-
+Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4,
+per introdurre un file locking che come dice il nome, fosse effettivo
+indipendentemente dai controlli eseguiti da un processo. Con il
+\textit{mandatory locking} infatti è possibile far eseguire il blocco del file
+direttamente al sistema, così che anche qualora non si predisponessero le
+opportune verifiche nei processi, questo verrebbe comunque rispettato.
+
+Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
+utilizzo particolare del bit \acr{suid}. Se si ricorda quanto esposto in
+\secref{sec:file_suid_sgid}), esso viene di norma utlizzato per cambiare
+l'\textit{effective user ID} con cui viene eseguito un programma, ed è
+pertanto sempre associato alla presenza del permesso di esecuzione. Impostando
+questo bit su un file senza permesso di esecuzione in un sistema che supporta
+il \textit{mandatory locking}, fa sì che quest'ultimo venga attivato per il
+file in questione. In questo modo una combinaizone dei permessi
+originariamente non contemplata, in quanto senza significato, diventa
+l'indicazione della presenza o meno del \textit{mandatory locking}.
projects / gapil.git / blobdiff