In questo capitolo affronteremo le tematiche della gestione avanzata delle
funzioni di input/ouput, prenderemo in esame il \textit{file locking}, la
-gestione dell'I/O non bloccante e multiplexato, per concludere con la gestione
-dei file mappati in memoria.
+gestione dell'input/output da più file, per concludere con la gestione dei
+file mappati in memoria.
+\section{L'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 un'altro potrebbe essere
+libero.
-\section{File locking}
-\label{sec:file_locking}
-
+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.
-\subsection{Il \textit{mandatory locking}}
-\label{sec:file_mand_locking}
+\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.
-\section{I/O non bloccante}
-\label{sec:file_noblocking}
+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}.
+Esistono molti casi però in cui non si vuole che questo avvenga
-\section{I/O multiplexato}
-\label{sec:file_multiplexing}
%\section{I/O asincrono}
%distinguere da quale file proviene l'attività che ha causato l'emissione del
%segnale).
+\subsection{L'I/O asincrono}
+\label{sec:file_asyncronous_io}
+
+
+
+\subsection{Le funzioni \func{poll} e \func{select}}
+\label{sec:file_multiplexing}
+
+
+
+
+
+
+\section{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.
+
+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.
+
+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{Il \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,
+
+
+
\section{File mappati in memoria}
\label{sec:file_memory_map}
programmi eseguiti in background, che altrimenti sarebbero interrotti da una
successiva pressione di \texttt{C-c} o \texttt{C-y}.
-Per quanto riguarda tutte le altre system call esse vengono tradizionalmente
-classificate, proprio in base al loro comportamento nei confronti dei segnali,
-in \textsl{lente} (\textit{slow}) e \textsl{veloci} (\textit{fast}). La gran
-parte appartiene a quest'ultima categoria che non è influenzata dall'arrivo di
-un segnale. In tal caso un eventuale manipolatore viene sempre eseguito dopo
-che la system call è stata completata. Esse sono dette \textsl{veloci} proprio
-in quanto la loro esecuzione è sostanzialmente immediata e attendere per
-eseguire un manipolatore non comporta nessun inconveniente.
-
-Esistono però dei casi in cui questo non è possibile perché renderebbe
-impossibile una risposta pronta al segnale. In generale questo avviene tutte
-le volte che si ha a che fare con system call che possono bloccarsi
-indefinitamente, (quelle che, per questo, vengono chiamate \textsl{lente}). Un
-elenco dei casi in cui si presenta questa situazione è il seguente:
+Per quanto riguarda il comportamento di tutte le altre system call si danno
+sostanzialmente due casi, a seconda che esse siano \textsl{lente}
+(\textit{slow}) o \textsl{veloci} (\textit{fast}). La gran parte di esse
+appartiene a quest'ultima categoria, che non è influenzata dall'arrivo di un
+segnale. Esse sono dette \textsl{veloci} in quanto la loro esecuzione è
+sostanzialmente immediata; la risposta al segnale viene sempre data dopo che
+la system call è stata completata, in quanto attendere per eseguire un
+manipolatore non comporta nessun inconveniente.
+
+In alcuni casi però alcune system call (che per questo motivo vengono chiamate
+\textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può
+attendere la conclusione della sistem call, perché questo renderebbe
+impossibile una risposta pronta al segnale, per cui il manipolatore viene
+eseguito prima che la system call sia ritornata. Un elenco dei casi in cui si
+presenta questa situazione è il seguente:
\begin{itemize}
-\item lettura da file che possono bloccarsi in attesa di dati non ancora
- presenti (come per certi file di dispositivo, la rete o le pipe).
-\item scrittura sugli stessi file, nel caso in cui dati non possano essere
+\item la lettura da file che possono bloccarsi in attesa di dati non ancora
+ presenti (come per certi file di dispositivo, i socket o le pipe).
+\item la scrittura sugli stessi file, nel caso in cui dati non possano essere
accettati immediatamente.
-\item apertura di un file di dispositivo che richiede operazioni non immediate
- per una una risposta.
-\item operazioni eseguite con \func{ioctl} che non è detto possano essere
+\item l'apertura di un file di dispositivo che richiede operazioni non
+ immediate per una una risposta.
+\item le operazioni eseguite con \func{ioctl} che non è detto possano essere
eseguite immediatamente.
\item le funzioni di intercomunicazione che si bloccano in attesa di risposte
da altri processi.
projects / gapil.git / commitdiff