\section{L'\textit{I/O multiplexing}}
\label{sec:file_multiplexing}
+
Uno dei problemi che si presentano quando si deve operare contemporaneamente
su molti file usando le funzioni illustrate in
cap.~\ref{cha:file_unix_interface} e cap.~\ref{cha:files_std_interface} è che
che questo fosse un puntatore valido, anche se poi veniva ignorato, a
partire dal 2.6.9 si può specificare anche un valore \texttt{NULL}.}
-
-
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
sola modalità possibile, ad esempio la condizione può essere riconosciuta
anche con il fatto che sono stati restituiti meno dati di quelli richiesti.
-Come le precedenti \func{select} e \func{poll}, le funzioni dell'interfaccia
-di \textit{epoll} vengono utilizzate prevalentemente con i server di rete,
-quando si devono tenere sotto osservazione un gran numero di socket; per
-questo motivo rimandiamo di nuovo la trattazione di un esempio concreto a
-quando avremo esaminato in dettaglio le caratteristiche dei socket, in
-particolare si potrà trovare un programma che utilizza questa interfaccia in
-sez.~\ref{sec:TCP_sock_multiplexing}.
+Come già per \func{select} e \func{poll} anche per l'interfaccia di
+\textit{epoll} si pone il problema di gestire l'attesa di segnali e di dati
+contemponeamente, per far questo di nuovo è necessaria una variante della
+funzione di attesa che consenta di reimpostare all'uscita una maschera di
+segnali, analoga alle precedenti estensioni \func{pselect} e \func{ppoll}; in
+questo caso la funzione si chiama \funcd{epoll\_pwait}\footnote{introdotta a
+ partire dal kernel 2.6.19.} ed il suo prototipo è:
+\begin{prototype}{sys/epoll.h}
+ {int epoll\_pwait(int epfd, struct epoll\_event * events, int maxevents,
+ int timeout, const sigset\_t *sigmask)}
-\itindend{epoll}
+ Attende che uno dei file descriptor osservati sia pronto, mascherando i
+ segnali.
+
+ \bodydesc{La funzione restituisce il numero di file descriptor pronti in
+ caso di successo o $-1$ in caso di errore, nel qual caso \var{errno}
+ assumerà uno dei valori già visti con \funcd{epoll\_wait}.
+}
+\end{prototype}
+La funzione è del tutto analoga \funcd{epoll\_wait}, soltanto che alla sua
+uscita viene ripristinata la maschera di segnali originale, sostituita durante
+l'esecuzione da quella impostata con l'argomento \param{sigmask}; in sostanza
+la chiamata a questa funzione è equivalente al seguente codice, eseguito però
+in maniera atomica:
+\includecodesnip{listati/epoll_pwait_means.c}
+
+Si tenga presente che come le precedenti funzioni di \textit{I/O multiplexing}
+anche le funzioni dell'interfaccia di \textit{epoll} vengono utilizzate
+prevalentemente con i server di rete, quando si devono tenere sotto
+osservazione un gran numero di socket; per questo motivo rimandiamo di nuovo
+la trattazione di un esempio concreto a quando avremo esaminato in dettaglio
+le caratteristiche dei socket, in particolare si potrà trovare un programma
+che utilizza questa interfaccia in sez.~\ref{sec:TCP_sock_multiplexing}.
+
+\itindend{epoll}
\section{L'accesso \textsl{asincrono} ai file}
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 \const{F\_SETFL} (vedi
-sez.~\ref{sec:file_fcntl}).
-
-In realtà parlare di apertura in modalità asincrona non significa che le
-operazioni di lettura o scrittura del file vengono eseguite in modo asincrono
-(tratteremo questo, che è ciò che più propriamente viene chiamato \textsl{I/O
- asincrono}, in sez.~\ref{sec:file_asyncronous_io}), quanto dell'attivazione
-un meccanismo di notifica asincrona delle variazione dello stato del file
-descriptor aperto in questo modo. Quello che succede in questo caso è che il
-sistema genera un segnale (normalmente \const{SIGIO}, ma è possibile usarne
-altri con il comando \const{F\_SETSIG} di \func{fcntl}) tutte le volte che
-diventa possibile leggere o scrivere dal file descriptor che si è posto in
-questa modalità.\footnote{questa modalità non è utilizzabile con i file
- ordinari ma solo con socket, file di terminale o pseudo terminale, e, a
- partire dal kernel 2.6, anche per fifo e pipe.}
-
-Si può inoltre selezionare, con il comando \const{F\_SETOWN} di \func{fcntl},
-quale processo (o gruppo di processi) riceverà il segnale. Se pertanto si
-effettuano le operazioni di I/O in risposta alla ricezione del segnale non ci
-sarà più la necessità di restare bloccati in attesa della disponibilità di
-accesso ai file.
+sez.~\ref{sec:file_fcntl}). In realtà parlare di apertura in modalità
+asincrona non significa che le operazioni di lettura o scrittura del file
+vengono eseguite in modo asincrono (tratteremo questo, che è ciò che più
+propriamente viene chiamato \textsl{I/O asincrono}, in
+sez.~\ref{sec:file_asyncronous_io}), quanto dell'attivazione un meccanismo di
+notifica asincrona delle variazione dello stato del file descriptor aperto in
+questo modo.
+
+Quello che succede è che per tutti i file posti in questa modalità\footnote{si
+ tenga presente però che essa non è utilizzabile con i file ordinari ma solo
+ con socket, file di terminale o pseudo terminale, ed anche, a partire dal
+ kernel 2.6, anche per fifo e pipe.} il sistema genera un apposito segnale,
+\const{SIGIO}, tutte le volte che diventa possibile leggere o scrivere dal
+file descriptor che si è posto in questa modalità. Inoltre è possibile, come
+illustrato in sez.~\ref{sec:file_fcntl}, selezionare con il comando
+\const{F\_SETOWN} di \func{fcntl} quale processo o quale gruppo di processi
+dovrà ricevere il segnale. In questo modo diventa possibile effettuare le
+operazioni di I/O in risposta alla ricezione del segnale, e non ci sarà più la
+necessità di restare bloccati in attesa della disponibilità di accesso ai
+file.
+
+% TODO: per i thread l'uso di F_SETOWN ha un significato diverso
Per questo motivo Stevens, ed anche le pagine di manuale di Linux, chiamano
questa modalità ``\textit{Signal driven I/O}''. Si tratta di un'altra
di scrittura (\textit{write lease}). Nel primo caso la notifica avviene quando
un altro processo esegue l'apertura del file in scrittura o usa
\func{truncate} per troncarlo. Nel secondo caso la notifica avviene anche se
-il file viene aperto il lettura; in quest'ultimo caso però il \textit{lease}
+il file viene aperto in lettura; in quest'ultimo caso però il \textit{lease}
può essere ottenuto solo se nessun altro processo ha aperto lo stesso file.
Come accennato in sez.~\ref{sec:file_fcntl} il comando di \func{fcntl} che
cosiddetto \textit{memory-mapped I/O}, che, attraverso il meccanismo della
\textsl{paginazione} \index{paginazione} usato dalla memoria virtuale (vedi
sez.~\ref{sec:proc_mem_gen}), permette di \textsl{mappare} il contenuto di un
-file in una sezione dello spazio di indirizzi del processo.
- che lo ha allocato
+file in una sezione dello spazio di indirizzi del processo che lo ha allocato.
+
\begin{figure}[htb]
\centering
- \includegraphics[width=12cm]{img/mmap_layout}
+ \includegraphics[width=14cm]{img/mmap_layout}
\caption{Disposizione della memoria di un processo quando si esegue la
mappatura in memoria di un file.}
\label{fig:file_mmap_layout}
ignorati.\footnotemark\\
\const{MAP\_ANON} & Sinonimo di \const{MAP\_ANONYMOUS}, deprecato.\\
\const{MAP\_FILE} & Valore di compatibilità, ignorato.\\
- \const{MAP\_32BIT} & Esegue la mappatura sui primi 2GiB dello spazio
+ \const{MAP\_32BIT} & Esegue la mappatura sui primi 2Gb dello spazio
degli indirizzi, viene supportato solo sulle
piattaforme \texttt{x86-64} per compatibilità con
le applicazioni a 32 bit. Viene ignorato se si è
\label{tab:file_mmap_flag}
\end{table}
+\footnotetext[68]{dato che tutti faranno riferimento alle stesse pagine di
+ memoria.}
+
+\footnotetext[69]{l'uso di questo flag con \const{MAP\_SHARED} è stato
+ implementato in Linux a partire dai kernel della serie 2.4.x; esso consente
+ di creare segmenti di memoria condivisa e torneremo sul suo utilizzo in
+ sez.~\ref{sec:ipc_mmap_anonymous}.}
+
+\footnotetext{questo flag ed il precedente \const{MAP\_POPULATE} sono stati
+ introdotti nel kernel 2.5.46 insieme alla mappatura non lineare di cui
+ parleremo più avanti.}
Gli effetti dell'accesso ad una zona di memoria mappata su file possono essere
piuttosto complessi, essi si possono comprendere solo tenendo presente che
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 \index{paginazione}, la mappatura in memoria non può che essere
+\index{paginazione} 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.
-\footnotetext[68]{dato che tutti faranno riferimento alle stesse pagine di
- memoria.}
-
-\footnotetext[69]{l'uso di questo flag con \const{MAP\_SHARED} è stato
- implementato in Linux a partire dai kernel della serie 2.4.x; esso consente
- di creare segmenti di memoria condivisa e torneremo sul suo utilizzo in
- sez.~\ref{sec:ipc_mmap_anonymous}.}
-
-\footnotetext{questo flag ed il precedente \const{MAP\_POPULATE} sono stati
- introdotti nel kernel 2.5.46 insieme alla mappatura non lineare di cui
- parleremo più avanti.}
-
\begin{figure}[!htb]
\centering
- \includegraphics[height=6cm]{img/mmap_boundary}
+ \includegraphics[height=6.5cm]{img/mmap_boundary}
\caption{Schema della mappatura in memoria di una sezione di file di
dimensioni non corrispondenti al bordo di una pagina.}
\label{fig:file_mmap_boundary}
\end{figure}
-
Il caso più comune è quello illustrato in fig.~\ref{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
essere utile per il linker dinamico, in particolare quando viene effettuato
il \textit{prelink} delle applicazioni.}
-\itindend{memory~mapping}
+Per i vantaggi illustrati all'inizio del paragrafo l'interfaccia del
+\textit{memory mapped I/O} viene usata da una grande varietà di programmi,
+spesso con esigenze molto diverse fra di loro riguardo le modalità con cui
+verranno eseguiti gli accessi ad un file; è ad esempio molto comune per i
+database effettuare accessi ai dati in maniera pressoché casuale, mentre un
+riproduttore audio o video eseguirà per lo più letture sequenziali.
+
+Per migliorare le prestazioni a seconda di queste modalità di accesso è
+disponibile una apposita funzione, \funcd{madvise},\footnote{tratteremo in
+ sez.~\ref{sec:file_fadvise} le funzioni che consentono di ottimizzare
+ l'accesso ai file con l'interfaccia classica.} che consente di fornire al
+kernel delle indicazioni su dette modalità, così che possano essere adottate
+le opportune strategie di ottimizzazione. Il suo prototipo è:
+\begin{functions}
+ \headdecl{sys/mman.h}
+
+ \funcdecl{int madvise(void *start, size\_t length, int advise)}
+
+ Fornisci indicazioni sull'uso di un \textit{memory mapping}.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EAGAIN}] .
+ \item[\errcode{EBADF}] .
+ \item[\errcode{EINVAL}] .
+ \item[\errcode{EIO}] .
+ \item[\errcode{ENOMEM}] .
+ \end{errlist}
+ }
+\end{functions}
+
+
% TODO documentare \func{madvise}
+\itindend{memory~mapping}
+
\subsection{I/O vettorizzato: \func{readv} e \func{writev}}
\label{sec:file_multiple_io}
% inserite nel kernel 2.6.30, vedi http://lwn.net/Articles/326818/
-\subsection{L'I/O diretto fra file descriptor: \func{sendfile} e \func{splice}}
+\subsection{L'I/O diretto fra file descriptor: \func{sendfile} e
+ \func{splice}}
\label{sec:file_sendfile_splice}
Uno dei problemi che si presentano nella gestione dell'I/O è quello in cui si
projects / gapil.git / blobdiff