-\chapter{I/O avanzato}
+\chapter{La gestione avanzata dei file}
\label{cha:file_advanced}
-In questo capitolo affronteremo le tematiche della gestione avanzata delle
-funzioni di input/ouput, prenderemo in esame il \textit{file locking}, la
-gestione dell'input/output da più file, per concludere con la gestione dei
-file mappati in memoria.
+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{L'I/O avanzato}
+\section{Le funzioni di I/O avanzato}
\label{sec:file_advanced_io}
-Uno dei problemi che ci si trova ad affrontare con le funzioni ordinarie
-trattate in \capref{cha:file_unix_interface} è quello in cui si devono
-eseguire su più di un file descriptor delle operazioni che possono bloccarsi:
-il problema è che mentre si è bloccati su un file su di un'altro potrebbero
-essere presenti dati da leggere.
-
-In questa sezione vedremo come si possono affrontare queste problematiche,
-quali sono le soluzioni possibili e quali i meccanismi il kernel e le librerie
-ci mettono a disposizione.
+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}
-Una prima soluzione per evitare di bloccarsi nelle operazioni di I/O è quella
-di utilizzare la modalità \textsl{non-bloccante}. 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.}
-In particolare le operazioni di lettura possono bloccarsi quando non ci sono
-dati disponibili sul descrittore su cui si sta operando.
+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 questi file 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 però è 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.
+
-Abbiamo già accennato in \secref{sec:file_open} che è possibile prevenire
-questo tipo di comportamento aprendo il file in modalità non bloccante,
-specificando il flag \macro{O\_NONBLOCK}. In questo caso le funzioni che si
-sarebbero bloccate ritornano immediatamente restituendo l'errore
-\macro{EAGAIN}.
-L'utilizzo di questa modalità di I/O permette allora di risolvere il problema
+\subsection{Le funzioni \func{poll} e \func{select}}
+\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{prototype}{sys/select.h}
+ {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 settata 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 mette il processo in stato di \textit{sleep} (vedi
+\tabref{tab:proc_proc_states}) fintanto che almeno uno dei file descriptor
+degli insiemo 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/select.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 settato 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
+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}, 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 però 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 getire l'\textit{I/O
+ multiplexing}, basata sulla funzione \func{poll}, 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 settata 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}
-%\section{I/O asincrono}
-%\label{sec:file_asynchronous}
-%Non supportato in Linux, in BSD e SRv4 c'è, ma usando il segnale \macro{SIGIO}
-%per indicare che i dati sono disponibili, può essere usato in maniera semplice
-%con un solo file per processo (altrimenti non sarebbe più possibile
-%distinguere da quale file proviene l'attività che ha causato l'emissione del
-%segnale).
\subsection{L'I/O asincrono}
\label{sec:file_asyncronous_io}
+Una modalità alternativa all'uso dell'I/O non bloccante è quella di fare
+ricorso all'I/O asincrono. Abbiamo accennato in \secref{sec:file_open} che è
+possibile, attraverso l'uso del flag \macro{O\_ASYNC}, aprire un file in
+modalità asincrona, così come è possibile settare questo flag attraverso l'uso
+di \func{fcntl}.
+In tal caso il sistema genera un segnale \macro{SIGIO} tutte le volte che sono
+presenti dei dati in input su un file aperto in questa modalità. Uno dei
+problemi che si presentavano con le prime implementazioni di questa modalità
+di I/O è che essa poteva essere usata in maniera semplice aprendo un solo file
+per processo, dato che altrimenti si sarebbe dovuto provvedere ad effettuare
+una serie di controlli su tutti i file aperti per distinguere a quale fosse
+dovuto l'emissione del segnale.
-\subsection{Le funzioni \func{poll} e \func{select}}
-\label{sec:file_multiplexing}
+Tutto questo adesso può essere evitato facendo ricorso alle informazioni
+restituite al manipolatore del segnale attraverso la struttura
+\var{siginfo\_t} (vedi \figref{fig:sig_siginfo_t}), il cui campo \var{si\_fd}
+riporta il file descriptor che ha generato il segnale.
+\subsection{File mappati in memoria}
+\label{sec:file_memory_map}
+
+
+\subsection{I/O multiplo}
+\label{sec:file_multiple_io}
-\section{File locking}
+\section{Il file locking}
\label{sec:file_locking}
-In \secref{sec:file_sharing} abbiamo preso in esame le mosalità in cui un
-sistema unix-like gestisce la condivisione dei file. 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.
+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; 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 imprevedebile il loro output sul file.
+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
+bloccare l'accesso al file da parte di altri processi, così da evitare le
sovrapposizioni, e garantire la atomicità delle operazioni di scrittura.
-\subsection{Il \textit{advisory locking}}
+\subsection{L'\textit{advisory locking}}
\label{sec:file_record_locking}
La prima modalità di file locking che è stata implementata nei sistemi
\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,
-\section{File mappati in memoria}
-\label{sec:file_memory_map}
-
%%% Local Variables:
projects / gapil.git / blobdiff