\subsection{Il \textit{Signal driven I/O}}
\label{sec:file_asyncronous_operation}
+\itindbeg{signal~driven~I/O}
+
Abbiamo accennato in sez.~\ref{sec:file_open} che è possibile, attraverso
l'uso del flag \const{O\_ASYNC},\footnote{l'uso del flag di \const{O\_ASYNC} e
dei comandi \const{F\_SETOWN} e \const{F\_GETOWN} per \func{fcntl} è
% TODO fare esempio che usa O_ASYNC
+\itindend{signal~driven~I/O}
+
+
\subsection{I meccanismi di notifica asincrona.}
\label{sec:file_asyncronous_lease}
\textit{lease breaker}, cerca di eseguire una \func{open} o una
\func{truncate} sul file del quale l'\textit{holder} detiene il
\textit{lease}.
-
La notifica avviene in maniera analoga a come illustrato in precedenza per
l'uso di \const{O\_ASYNC}: di default viene inviato al \textit{lease holder}
il segnale \const{SIGIO}, ma questo segnale può essere modificato usando il
Inoltre trattandosi di un file descriptor a tutti gli effetti, esso potrà
essere utilizzato come argomento per le funzioni \func{select} e \func{poll} e
-con l'interfaccia di \textit{epoll}; siccome gli eventi vengono notificati
-come dati disponibili in lettura, dette funzioni ritorneranno tutte le volte
-che si avrà un evento di notifica. Così, invece di dover utilizzare i
+con l'interfaccia di \textit{epoll};\footnote{ed a partire dal kernel 2.6.25 è
+ stato introdotto anche il supporto per il \itindex{signal~driven~I/O}
+ \texttt{signal-driven I/O} trattato in
+ sez.~\ref{sec:file_asyncronous_operation}.} siccome gli eventi vengono
+notificati come dati disponibili in lettura, dette funzioni ritorneranno tutte
+le volte che si avrà un evento di notifica. Così, invece di dover utilizzare i
segnali,\footnote{considerati una pessima scelta dal punto di vista
dell'interfaccia utente.} si potrà gestire l'osservazione degli eventi con
una qualunque delle modalità di \textit{I/O multiplexing} illustrate in
portato, per i kernel della serie 2.6,\footnote{per alcune motivazioni di
questa scelta si può fare riferimento a quanto illustrato da Linus Torvalds
in \href{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}
- {\texttt{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}}.}
+ {\textsf{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}}.}
alla decisione di consentire l'uso della funzione soltanto quando il file da
cui si legge supporta le operazioni di \textit{memory mapping} (vale a dire
non è un socket) e quello su cui si scrive è un socket; in tutti gli altri
stata la reinterpretazione che ne è stata fatta nell'implementazione su
Linux realizzata da Jens Anxboe, concetti che sono esposti sinteticamente
dallo stesso Linus Torvalds in \href{http://kerneltrap.org/node/6505}
- {\texttt{http://kerneltrap.org/node/6505}}.} si tratta semplicemente di una
+ {\textsf{http://kerneltrap.org/node/6505}}.} si tratta semplicemente di una
funzione che consente di fare in maniera del tutto generica delle operazioni
di trasferimento di dati fra un file e un buffer gestito interamente in kernel
space. In questo caso il cuore della funzione (e delle affini \func{vmsplice}
realizza le \textit{pipe} come un insieme di puntatori\footnote{per essere
precisi si tratta di un semplice buffer circolare, un buon articolo sul tema
si trova su \href{http://lwn.net/Articles/118750/}
- {\texttt{http://lwn.net/Articles/118750/}}.} alle pagine di memoria interna
+ {\textsf{http://lwn.net/Articles/118750/}}.} alle pagine di memoria interna
che contengono i dati, per questo una volta che i dati sono presenti nella
memoria del kernel tutto quello che viene fatto è creare i suddetti puntatori
ed aumentare il numero di referenze; questo significa che anche con \func{tee}
% TODO documentare \func{fallocate}, introdotta con il 2.6.23
% vedi http://lwn.net/Articles/226710/ e http://lwn.net/Articles/240571/
% http://kernelnewbies.org/Linux_2_6_23
+% \func{fallocate} con il 2.6.25 supporta pure XFS
+
%\subsection{L'utilizzo delle porte di I/O}
%\label{sec:file_io_port}
projects / gapil.git / blobdiff