Correzioni varie al codice ed alle relative citazioni

[gapil.git] / fileadv.tex

\chapter{La gestione avanzata dei file}
\label{cha:file_advanced}

In questo capitolo affronteremo le tematiche relative alla gestione avanzata
dei file, che non sono state trattate in \capref{cha:file_unix_interface},
dove ci si è limitati ad una panoramica delle funzioni base. In particolare
tratteremo delle funzioni di input/output avanzato e del \textit{file
  locking}.


\section{Le funzioni di I/O avanzato}
\label{sec:file_advanced_io}

In questa sezione esamineremo le funzioni che permettono una gestione più
sofisticata dell'I/O su file, a partire da quelle che permettono di gestire
l'accesso contemporaneo a più file, per concludere con la gestione dell'I/O
mappato in memoria.


\subsection{La modalità di I/O \textsl{non-bloccante}}
\label{sec:file_noblocking}

Abbiamo visto in \secref{sec:sig_gen_beha}, affrontando la suddivisione fra
\textit{fast} e \textit{slow} system call, che in certi casi le funzioni di
I/O possono bloccarsi indefinitamente.\footnote{si ricordi però che questo può
  accadere solo per le pipe, i socket ed alcuni file di dispositivo; sui file
  normali le funzioni di lettura e scrittura ritornano sempre subito.}  Ad
esempio le operazioni di lettura possono bloccarsi quando non ci sono dati
disponibili sul descrittore su cui si sta operando.

Questo comportamento causa uno dei problemi più comuni che ci si trova ad
affrontare nelle operazioni di I/O, che è quello che si verifica quando si
devono eseguire operazioni che possono bloccarsi su più file descriptor:
mentre si è bloccati su uno di essi su di un'altro potrebbero essere presenti
dei dati; così che nel migliore dei casi si avrebbe una lettura ritardata
inutilmente, e nel peggiore si potrebbe addirittura arrivare ad un deadlock.

Abbiamo già accennato in \secref{sec:file_open} che è possibile prevenire
questo tipo di comportamento aprendo un file in modalità
\textsl{non-bloccante}, attraverso l'uso del flag \macro{O\_NONBLOCK} nella
chiamata di \func{open}. In questo caso le funzioni di input/output che
altrimenti si sarebbero bloccate ritornano immediatamente, restituendo
l'errore \macro{EAGAIN}.

L'utilizzo di questa modalità di I/O permette di risolvere il problema
controllando a turno i vari file descriptor, in un ciclo in cui si ripete
l'accesso fintanto che esso non viene garantito.  Ovviamente questa tecnica,
detta \textit{polling}, è estremamente inefficiente: si tiene costantemente
impiegata la CPU solo per eseguire in continuazione delle system call che
nella gran parte dei casi falliranno. Per evitare questo, come vedremo in
\secref{sec:file_multiplexing}, è stata introdotta una nuova interfaccia di
programmazione, che comporta comunque l'uso della modalità di I/O non
bloccante.



\subsection{L'I/O multiplexing}
\label{sec:file_multiplexing}

Per superare il problema di dover usare il \textit{polling} per controllare la
possibilità di effettuare operazioni su un file aperto in modalità non
bloccante, sia BSD che System V hanno introdotto delle nuove funzioni in grado
di sospendere l'esecuzione di un processo in attesa che l'accesso diventi
possibile.  Il primo ad introdurre questa modalità di operazione, chiamata
usualmente \textit{I/O multiplexing}, è stato BSD,\footnote{la funzione è
  apparsa in BSD4.2 e standardizzata in BSD4.4, ma è stata portata su tutti i
  sistemi che supportano i \textit{socket}, compreso le varianti di System V.}
con la funzione \func{select}, il cui prototipo è:
\begin{functions}
  \headdecl{sys/time.h}
  \headdecl{sys/types.h}
  \headdecl{unistd.h}
  \funcdecl{int select(int n, fd\_set *readfds, fd\_set *writefds, fd\_set
    *exceptfds, struct timeval *timeout)}
  
  Attende che uno dei file descriptor degli insiemi specificati diventi
  attivo.
  
  \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 impostata ai valori:
  \begin{errlist}
  \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno
  degli insiemi.
  \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
  \item[\macro{EINVAL}] Si è specificato per \param{n} un valore negativo.
  \end{errlist}
  ed inoltre \macro{ENOMEM}.
}
\end{functions}

La funzione mette il processo in stato di \textit{sleep} (vedi
\tabref{tab:proc_proc_states}) fintanto che almeno uno dei file descriptor
degli insiemi specificati (\param{readfds}, \param{writefds} e
\param{exceptfds}), non diventa attivo, per un tempo massimo specificato da
\param{timeout}.

Per specificare quali file descriptor si intende \textsl{selezionare}, la
funzione usa un particolare oggetto, il \textit{file descriptor set},
identificato dal tipo \type{fd\_set}, che serve ad identificare un insieme di
file descriptor, (in maniera analoga a come un \textit{signal set}, vedi
\secref{sec:sig_sigset}, identifica un insieme di segnali). Per la
manipolazione di questi \textit{file descriptor set} si possono usare delle
opportune macro di preprocessore:
\begin{functions}
  \headdecl{sys/time.h}
  \headdecl{sys/types.h}
  \headdecl{unistd.h}
  \funcdecl{FD\_ZERO(fd\_set *set)}
  Inizializza l'insieme (vuoto).

  \funcdecl{FD\_SET(int fd, fd\_set *set)}
  Inserisce il file descriptor \param{fd} nell'insieme.

  \funcdecl{FD\_CLR(int fd, fd\_set *set)}
  Rimuove il file descriptor \param{fd} nell'insieme.
  
  \funcdecl{FD\_ISSET(int fd, fd\_set *set)}
  Controlla se il file descriptor \param{fd} è nell'insieme.
\end{functions}

In genere un \textit{file descriptor set} può contenere fino ad un massimo di
\macro{FD\_SETSIZE} file descriptor.  Questo valore in origine corrispondeva
al limite per il numero massimo di file aperti\footnote{ad esempio in Linux,
  fino alla serie 2.0.x, c'era un limite di 256 file per processo.}, ma
quando, come nelle versioni più recenti del kernel, non c'è più un limite
massimo, esso indica le dimensioni massime dei numeri usati nei \textit{file
  descriptor set}.

La funzione richiede di specificare tre insiemi distinti di file descriptor;
il primo, \param{readfds}, verrà osservato per rilevare la disponibilità di
effettuare una lettura, il secondo, \param{writefds}, per verificare la
possibilità effettuare una scrittura ed il terzo, \param{exceptfds}, per
verificare l'esistenza di condizioni eccezionali (come i messaggi urgenti su
un \textit{socket}\index{socket}, vedi \secref{sec:xxx_urgent}).

La funzione inoltre richiede anche di specificare, tramite l'argomento
\param{n}, un valore massimo del numero dei file descriptor usati
nell'insieme; si può usare il già citato \macro{FD\_SETSIZE}, oppure il numero
più alto dei file descriptor usati nei tre insiemi, aumentato di uno.

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 impostato a \macro{NULL} la funzione attende
indefinitamente. Si può specificare anche un tempo nullo (cioè una \var{struct
  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,
il valore zero indica sempre che si è raggiunto un timeout. Ciascuno dei tre
insiemi viene sovrascritto per indicare quale file descriptor è pronto per le
operazioni ad esso relative, in modo da poterlo controllare con la macro
\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},
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
  multiplexing}, basata sulla funzione \func{poll},\footnote{la funzione è
  prevista dallo standard XPG4, ed è stata introdotta in Linux come system
  call a partire dal kernel 2.1.23 e dalle \acr{libc} 5.4.28.} il cui prototipo è:
\begin{prototype}{sys/poll.h}
  {int poll(struct pollfd *ufds, unsigned int nfds, int timeout)}

La funzione attente un cambiamento di stato per uno dei file descriptor
specificati da \param{ufds}.
  
\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 impostata ai valori:
  \begin{errlist}
  \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno
  degli insiemi.
  \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
  \end{errlist}
  ed inoltre \macro{EFAULT} e \macro{ENOMEM}.}
\end{prototype}

La funzione tiene sotto controllo un numero \param{ndfs} di file descriptor
specificati attraverso un vettore di puntatori a strutture di tipo
\type{pollfd}, la cui definizione è riportata in \figref{fig:file_pollfd}.
Come \func{select} anche \func{poll} permette di interrompere l'attesa dopo un
certo tempo, che va specificato attraverso \param{timeout} in numero di
millisecondi (un valore negativo indica un'attesa indefinita).

\begin{figure}[!htb]
  \footnotesize \centering
  \begin{minipage}[c]{15cm}
    \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
struct pollfd {
        int fd;           /* file descriptor */
        short events;     /* requested events */
        short revents;    /* returned events */
};
    \end{lstlisting}
  \end{minipage} 
  \normalsize 
  \caption{La struttura \type{pollfd}, utilizzata per specificare le modalità
    di controllo di un file descriptor alla funzione \func{poll}.}
  \label{fig:file_pollfd}
\end{figure}

Per ciascun file da controllare deve essere opportunamente predisposta una
struttura \type{pollfd}; nel campo \var{fd} deve essere specificato il file
descriptor, mentre nel campo \var{events} il tipo di evento su cui si vuole
attendere; quest'ultimo deve essere specificato come maschera binaria dei
primi tre valori riportati in \tabref{tab:file_pollfd_flags} (gli altri
vengono utilizzati solo per \var{revents} come valori in uscita).

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|c|l|}
    \hline
    \textbf{Flag} & \textbf{Valore} & \textbf{Significato} \\
    \hline
    \hline
    \macro{POLLIN}    & 0x001 & È possibile la lettura immediata.\\
    \macro{POLLPRI}   & 0x002 & Sono presenti dati urgenti.\\
    \macro{POLLOUT}   & 0x004 & È possibile la scrittura immediata.\\
    \hline
    \macro{POLLERR}   & 0x008 & C'è una condizione di errore.\\
    \macro{POLLHUP}   & 0x010 & Si è verificato un hung-up.\\
    \macro{POLLNVAL}  & 0x020 & Il file descriptor non è aperto.\\
    \hline
    \macro{POLLRDNORM}& 0x040 & Sono disponibili in lettura dati normali.\\ 
    \macro{POLLRDBAND}& 0x080 & Sono disponibili in lettura dati ad alta 
                                priorità. \\
    \macro{POLLWRNORM}& 0x100 & È possibile la scrittura di dati normali.  \\ 
    \macro{POLLWRBAND}& 0x200 & È possibile la scrittura di dati ad 
                                alta priorità. \\
    \macro{POLLMSG}   & 0x400 & Estensione propria di Linux.\\
    \hline    
  \end{tabular}
  \caption{Costanti per l'identificazione dei vari bit dei campi
    \var{events} e \var{revents} di \type{pollfd}.}
  \label{tab:file_pollfd_flags}
\end{table}

La funzione ritorna, restituendo il numero di file per i quali si è verificata
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 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.

Lo standard POSIX è rimasto a lungo senza primitive per l'\textit{I/O
  multiplexing}, che è stata introdotto con le ultime revisioni dello standard
(POSIX 1003.1g-2000 e POSIX 1003.1-2001). Esso prevede che tutte le funzioni
ad esso relative vengano dichiarate nell'header \file{sys/select.h}, che
sostituisce i precedenti, ed aggiunge a \func{select} una nuova funzione
\func{pselect},\footnote{il supporto per lo standard POSIX 1003.1-2001, ed
  l'header \file{sys/select.h}, compaiono in Linux a partire dalle \acr{glibc}
  2.1. Le \acr{libc4} e \acr{libc5} non contengono questo header, le
  \acr{glibc} 2.0 contengono una definizione sbagliata di \func{psignal},
  senza l'argomento \param{sigmask}, la definizione corretta è presente dalle
  \acr{glibc} 2.1-2.2.1 se si è definito \macro{\_GNU\_SOURCE} e nelle
  \acr{glibc} 2.2.2-2.2.4 se si è definito \macro{\_XOPEN\_SOURCE} con valore
  maggiore di 600.} il cui prototipo è:
\begin{prototype}{sys/select.h}
  {int pselect(int n, fd\_set *readfds, fd\_set *writefds, fd\_set *exceptfds,
    struct timespec *timeout, sigset\_t *sigmask)}
  
  Attende che uno dei file descriptor degli insiemi specificati diventi
  attivo.
  
  \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 impostata ai valori:
  \begin{errlist}
  \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno
  degli insiemi.
  \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
  \item[\macro{EINVAL}] Si è specificato per \param{n} un valore negativo.
  \end{errlist}
  ed inoltre \macro{ENOMEM}.}
\end{prototype}

La funzione è sostanzialmente identica a \func{select}, solo che usa una
struttura \type{timespec} per indicare con maggiore precisione il timeout e
non ne aggiorna il valore in caso di interruzione, inoltre prende un argomento
aggiuntivo \param{sigmask} che è il puntatore ad una maschera di segnali (si
veda \secref{sec:sig_sigmask}). La maschera corrente viene sostituita da
questa immediatamente prima di eseguire l'attesa, e ripristinata al ritorno
della funzione.

L'uso di \param{sigmask} è stato introdotto allo scopo di prevenire possibili
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 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 test e riabilitandolo poi grazie all'uso di \param{sigmask}.



\subsection{L'\textsl{I/O asincrono}}
\label{sec:file_asyncronous_io}

Una modalità alternativa all'uso dell'\textit{I/O multiplexing} è quella di
fare ricorso al cosiddetto \textsl{I/O asincrono}. Il concetto base
dell'\textsl{I/O asincrono} è che le funzioni di I/O non attendono il
completamento delle operazioni prima di ritornare, così che il processo non
viene bloccato.  In questo modo diventa ad esempio possibile effettuare una
richiesta preventiva di dati, in modo da poter effettuare in contemporanea le
operazioni di calcolo e quelle di I/O.

Abbiamo accennato in \secref{sec:file_open} che è possibile, attraverso l'uso
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à impostando questo flag attraverso
l'uso di \func{fcntl} con il comando \macro{F\_SETFL} (vedi
\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
descriptor; quello che succede è che il sistema genera un segnale (normalmente
\macro{SIGIO}, ma è possibile usarne altri) tutte le volte che diventa
possibile leggere o scrivere dal file descriptor che si è posto in questa
modalità. Si può inoltre selezionare, con il comando \macro{F\_SETOWN} di
\func{fcntl}, quale processo (o gruppo di processi) riceverà il segnale. 

In questo modo si può evitare l'uso delle funzioni \func{poll} o \func{select}
che, quando vengono usate con un numero molto grande di file descriptor, non
hanno buone prestazioni. In tal caso infatti la maggior parte del loro tempo
di esecuzione è impegnato ad eseguire una scansione su tutti i file descriptor
tenuti sotto controllo per determinare quali di essi (in genere una piccola
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 sono
più di uno, qual'è il file descriptor responsabile dell'emissione del segnale.
Linux però supporta le estensioni POSIX.1b dei segnali che permettono di
superare il problema facendo ricorso alle informazioni aggiuntive restituite
attraverso la struttura \type{siginfo\_t}, utilizzando la forma estesa
\var{sa\_sigaction} del manipolatore (si riveda quanto illustrato in
\secref{sec:sig_sigaction}).

Per far questo però occorre utilizzare le funzionalità dei segnali real-time
(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 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
  segnale è stato generato a causa di attività nell'I/O asincrono.} di
\type{siginfo\_t}, troverà nel campo \var{si\_fd} il valore del file
descriptor che ha generato il segnale.

Un secondo vantaggio dell'uso dei segnali real-time è che essendo dotati di
una coda di consegna ogni segnale sarà associato ad uno solo file descriptor;
inoltre sarà possibile stabilire delle priorità nella risposta a seconda del
segnale usato. In questo modo si può identificare immediatamente un file su
cui l'accesso è diventato possibile evitando completamente l'uso di funzioni
come \func{poll} e \func{select}, almeno fintanto che non si satura la coda;
si eccedono le dimensioni di quest'ultima; in tal caso infatti il kernel, non
potendo più assicurare il comportamento corretto per un segnale real-time,
invierà al suo posto un \var{SIGIO}, su cui si accumuleranno tutti i segnali
in eccesso, e si dovrà determinare al solito modo quali sono i file diventati
attivi.

Benché la modalità di apertura asincrona di un file possa risultare utile in
varie occasioni (in particolar modo con i socket e gli altri file per i quali
le funzioni di I/O sono system call lente), essa è comunque limitata alla
notifica della disponibilità del file descriptor per le operazioni di I/O, e
non ad uno svolgimento asincrono delle medesime.  Lo standard POSIX.1b
definisce anche una interfaccia apposita per l'I/O asincrono, che prevede un
insieme di funzioni dedicate, completamente separate rispetto a quelle usate
normalmente.

In generale questa interfaccia è completamente astratta e può essere
implementata sia direttamente nel kernel, che in user space attraverso l'uso
di thread. Al momento\footnote{fino ai kernel della serie 2.4.x, nella serie
  2.5.x è però iniziato un lavoro completo di riscrittura di tutto il sistema
  di I/O, che prevede anche l'introduzione di un nuovo layer per l'I/O
  asincrono.} esiste una sola versione stabile di questa interfaccia, quella
delle \acr{glibc}, che è realizzata completamente in user space.  Esistono
comunque vari progetti sperimentali (come il KAIO della SGI, o i patch di
Benjamin La Haise) che prevedono un supporto diretto da parte del kernel.

Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate
attraverso l'uso di una apposita struttura \type{aiocb} (il cui nome sta per
\textit{asyncronous I/O control block}), che viene passata come argomento a
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à dell'interfaccia per l'I/O asincrono.

\begin{figure}[!htb]
  \footnotesize \centering
  \begin{minipage}[c]{15cm}
    \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
struct aiocb
{
    int aio_fildes;               /* File descriptor.  */
    off_t aio_offset;             /* File offset */
    int aio_lio_opcode;           /* Operation to be performed.  */
    int aio_reqprio;              /* Request priority offset.  */
    volatile void *aio_buf;       /* Location of buffer.  */
    size_t aio_nbytes;            /* Length of transfer.  */
    struct sigevent aio_sigevent; /* Signal number and value.  */
};
    \end{lstlisting}
  \end{minipage} 
  \normalsize 
  \caption{La struttura \type{aiocb}, usata per il controllo dell'I/O
    asincrono.}
  \label{fig:file_aiocb}
\end{figure}

Le operazioni di I/O asincrono possono essere effettuate solo su un file già
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.

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 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 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]
  \footnotesize \centering
  \begin{minipage}[c]{15cm}
    \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
struct sigevent
{
    sigval_t sigev_value;
    int sigev_signo;
    int sigev_notify;
    sigev_notify_function;
    sigev_notify_attributes;
};
    \end{lstlisting}
  \end{minipage} 
  \normalsize 
  \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}

Infine il campo \var{aio\_sigevent} è una struttura di tipo \type{sigevent}
che serve a specificare il modo in cui si vuole che venga effettuata la
notifica del completamento delle operazioni richieste. La struttura è
riportata in \secref{fig:file_sigevent}; il campo \var{sigev\_notify} è quello
che indica le modalità della notifica, esso può assumere i tre valori:
\begin{basedescript}{\desclabelwidth{3.0cm}}
\item[\macro{SIGEV\_NONE}]   Non viene inviata nessuna notifica.
\item[\macro{SIGEV\_SIGNAL}] La notifica viene effettuata inviando al processo
  chiamante il segnale specificato nel campo \var{sigev\_signo}, se il
  manipolatore è installato con \macro{SA\_SIGINFO}, il gli verrà restituito
  il valore di \var{sigev\_value} in come valore del campo \var{si\_value} per
  \type{siginfo\_t}.
\item[\macro{SIGEV\_THREAD}] La notifica viene effettuata creando un nuovo
  thread che esegue la funzione specificata da \var{sigev\_notify\_function},
  con gli attributi specificati da \var{sigev\_notify\_attribute}.
\end{basedescript}

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}

  \funcdecl{int aio\_read(struct aiocb *aiocbp)}
  Richiede una lettura asincrona secondo quanto specificato con \param{aiocbp}.

  \funcdecl{int aio\_write(struct aiocb *aiocbp)}
  Richiede una scrittura asincrona secondo quanto specificato con
  \param{aiocbp}.
  
  \bodydesc{Le funzioni restituiscono 0 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{ENOSYS}] La funzione non è implementata.
  \item[\macro{EINVAL}] Si è specificato un valore non valido per i campi
    \var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}.
  \item[\macro{EAGAIN}] La coda delle richieste è momentaneamente piena.
  \end{errlist}
}
\end{functions}

Entrambe le funzioni ritornano immediatamente dopo aver messo in coda la
richiesta, o in caso di errore. Non è detto che gli errori \macro{EBADF} ed
\macro{EINVAL} siano rilevati immediatamente al momento della chiamata,
potrebbero anche emergere nelle fasi successive delle operazioni. Lettura e
scrittura avvengono alla posizione indicata da \var{aio\_offset}, a meno che
il file non sia stato aperto in \textit{append mode} (vedi
\secref{sec:file_open}), nel qual caso le scritture vengono effettuate
comunque alla fine de file, nell'ordine delle chiamate a \func{aio\_write}.

Si tenga inoltre presente che deallocare la memoria indirizzata da
\param{aiocbp} o modificarne i valori prima della conclusione di una
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 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)}  

  Determina lo stato di errore delle operazioni di I/O associate a
  \param{aiocbp}.
  
  \bodydesc{La funzione restituisce 0 se le operazioni si sono concluse con
    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 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)} 

Recupera il valore dello stato di ritorno delle operazioni di I/O associate a
\param{aiocbp}.
  
\bodydesc{La funzione restituisce lo stato di uscita dell'operazione
  eseguita.}
\end{prototype}

La funzione deve essere chiamata una sola volte per ciascuna operazione
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 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
asincrono non verrebbero liberate, rischiando di arrivare ad un loro
esaurimento.

Oltre alle operazioni di lettura e scrittura l'interfaccia POSIX.1b mette a
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 eseguita in maniera asincrona; il suo prototipo
è:
\begin{prototype}{aio.h}
{ssize\_t aio\_return(int op, struct aiocb *aiocbp)} 

Richiede la sincronizzazione dei dati per il file indicato da \param{aiocbp}.
  
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
  errore, che può essere, con le stesse modalità di \func{aio\_read},
  \macro{EAGAIN}, \macro{EBADF} o \macro{EINVAL}.}
\end{prototype}

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
relativi ad eventuali operazioni richieste successivamente. Se si è
specificato un meccanismo di notifica questo sarà innescato una volta che le
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 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 è:
\begin{prototype}{aio.h}
{int aio\_cancel(int fildes, struct aiocb *aiocbp)} 

Richiede la cancellazione delle operazioni sul file \param{fildes} specificate
da \param{aiocbp}.
  
\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}, 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 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)}
  
  Attende, per un massimo di \param{timeout}, il completamento di una delle
  operazioni specificate da \param{list}.
  
  \bodydesc{La funzione restituisce 0 se una (o più) operazioni sono state
    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}.
    \item[\macro{ENOSYS}] La funzione non è implementata.
    \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
    \end{errlist}
  }
\end{prototype}

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)}
  
  Richiede l'esecuzione delle operazioni di I/O elencata da \param{list},
  secondo la modalità \param{mode}.
  
  \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{EAGAIN}] Nessuna operazione è stata completata entro
      \param{timeout}.
    \item[\macro{ENOSYS}] La funzione non è implementata.
    \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
    \end{errlist}
  }
\end{prototype}

La funzione esegue la richiesta delle \param{nent} operazioni indicate dalla
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
specifica \macro{LIO\_NOWAIT} la funzione ritorna immediatamente dopo aver
messo in coda tutte le richieste. In questo caso il chiamante può richiedere
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 vettorizzato}
\label{sec:file_multiple_io}

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. 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 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, per cui si può parlare tanto di file mappato in
memoria, quanto di memoria mappata su file.

\begin{figure}[htb]
  \centering
  \includegraphics[width=9.5cm]{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} non 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. 


\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}


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à di accesso con cui si è aperto il file.

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
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 violazione di accesso (\macro{SIGSEGV}), dato che
i permessi sul segmento di memoria relativo non consentono questo tipo di
accesso.

È invece assai diversa la questione relativa agli accessi al di fuori della
regione di cui si è richiesta la mappatura. A prima vista infatti si potrebbe
ritenere che anch'essi debbano generare un segnale di violazione di accesso;
questo però non tiene conto del fatto che, essendo basata sul meccanismo della
paginazione, la mappatura in memoria non può che essere eseguita su un
segmento di dimensioni rigorosamente multiple di quelle di una pagina, ed in
generale queste potranno non corrispondere alle dimensioni effettive del file
o della sezione che si vuole mappare. Il caso più comune è 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à il file sarà 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}


In questo caso è possibile accedere a quella zona di memoria che eccede le
dimensioni specificate da \param{lenght}, senza ottenere un \macro{SIGSEGV}
poiché essa è presente nello spazio di indirizzi del processo, anche se non è
mappata sul file. Il comportamento del sistema è quello di restituire un
valore nullo per quanto viene letto, e di non riportare su file quanto viene
scritto.

Un caso più complesso è quello che si viene a creare quando le dimensioni del
file mappato sono più corte delle dimensioni della mappatura, oppure quando il
file è stato troncato, dopo che è stato mappato, ad una dimensione inferiore a
quella della mappatura in memoria.

\begin{figure}[htb]
  \centering
  \includegraphics[width=13cm]{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 questa situazione, per la sezione di pagina parzialmente coperta dal
contenuto del file, vale esattamente quanto visto in precedenza; invece per la
parte che eccede, fino alle dimensioni date da \param{length}, l'accesso non
sarà più possibile, ma il segnale emesso non sarà \macro{SIGSEGV}, ma
\macro{SIGBUS}, come illustrato in \figref{fig:file_mmap_exceed}.

Non tutti i file possono venire mappati in memoria, dato che, come illustrato
in \figref{fig:file_mmap_layout}, la mappatura introduce una corrispondenza
biunivoca fra una sezione di un file ed una sezione di memoria. Questo
comporta che ad esempio non è possibile mappare in memoria file descriptor
relativi a pipe, socket e fifo, per i 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}). Si tenga presente però che esistono anche casi di
dispositivi (un esempio è l'interfaccia al ponte PCI-VME del chip Universe)
che sono utilizzabili solo con questa interfaccia.

Dato che passando attraverso una \func{fork} lo spazio di indirizzi viene
copiato integralmente, 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 (di cui si è trattato 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{cha: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 trasporterà dal disco in memoria quella sezione del file, perciò è
del tutto imprevedibile il risultato della modifica di un file nei confronti
del contenuto della memoria mappata su cui è mappato.

Per quanto appena visto, è sempre 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.

\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}

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.

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}
\label{sec:file_locking}

In \secref{sec:file_sharing} abbiamo preso in esame le modalità in cui un
sistema unix-like gestisce la condivisione dei file da parte di processi
diversi. In quell'occasione si è visto come, con l'eccezione dei file aperti
in \textit{append mode}, quando più processi scrivono contemporaneamente sullo
stesso file non è possibile determinare la sequenza in cui essi opereranno.

Questo causa la possibilità di race condition\index{race condition}; in
generale le situazioni più comuni sono due: l'interazione fra un processo che
scrive e altri che leggono, in cui questi ultimi possono leggere informazioni
scritte solo in maniera parziale o incompleta; o quella in cui diversi
processi scrivono, mescolando in maniera imprevedibile il loro output sul
file.

In tutti questi casi il \textit{file locking} è la tecnica che permette di
evitare le race condition, attraverso una serie di funzioni che permettono di
bloccare l'accesso al file da parte di altri processi, così da evitare le
sovrapposizioni, e garantire la atomicità delle operazioni di scrittura.


\subsection{L'\textit{advisory locking}}
\label{sec:file_record_locking}

La prima modalità di file locking che è stata implementata nei sistemi
unix-like è quella che viene usualmente chiamata \textit{advisory locking}, in
quanto è il processo, e non il sistema, che si incarica di verificare se
esiste una condizione di blocco per l'accesso ai file.




\subsection{Il \textit{mandatory locking}}
\label{sec:file_mand_locking}

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 utilizzato per cambiare
l'userid effettivo 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}.



%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "gapil"
%%% End: