\itindend{epoll}
+\subsection{La notifica di eventi tramite file descriptor}
+\label{sec:sig_signalfd_eventfd}
+
+Abbiamo visto in sez.~\ref{sec:file_select} come il meccanismo classico delle
+notifiche di eventi tramite i segnali, presente da sempre nei sistemi
+unix-like, porti a novevoli problemi nell'interazione con le funzioni per
+l'I/O multiplexing, tanto che per evitare possibili \itindex{race~condition}
+\textit{race condition} sono state introtte estensioni dello standard POSIX e
+funzioni apposite come \func{pselect}, \func{ppoll} e \funcd{epoll\_pwait}.
+
+Benché i segnali siano il meccanismo più usato per effettuare notifiche ai
+processi, la loro interfaccia di programmazione, che comporta l'esecuzione di
+una funzione di gestione in maniera asincrona e totalmente scorrelata
+dall'ordinario flusso di esecuzione del processo, si è però dimostrata quasi
+subito assai problematica. Oltre ai limiti relativi ai limiti al cosa si può
+fare all'interno della funzione del gestore di segnali (quelli illustrati in
+sez.~\ref{sec:sig_signal_handler}), c'è il problema più generale consistente
+nel fatto che questa modalità di funzionamento cozza con le altre interfacce
+di programmazione previste dal sistema in cui invece si opera in maniera
+\textsl{sincrona}, e che porta ai problemi relativi alla interruzione delle
+\index{system~call~lente} system call bloccanti.
+
+In questo caso infatti si aspetta che il processo gestisca gli eventi (che
+causano l'uscita dalla \index{system~call~lente} system call bloccante)
+generando le opportune risposte, mentre con l'arrivo di un segnale ci si trova
+alla possibilità di avere interruzioni asincrone in cui possono essere
+eseguite operazioni fuori dal resto dal flusso ordinario del programma e
+quindi la necessità gestire le interruzioni ed evitare possibili
+\itindex{race~condition} \textit{race conditions}.\footnote{in sostanza se non
+ fosse per i segnali non ci sarebbe da doversi preoccupare, fintanto che si
+ effettuano operazioni all'interno dello stesso, della non atomicità (si
+ ricordi quanto detto in sez.~\ref{sec:proc_atom_oper}) delle
+ \index{system~call~lente} system call lente che vengono interrotte e devono
+ essere riavviate.}
+
+Abbiamo visto però in sez.~\ref{sec:sig_real_time} che insieme ai segnali
+\textit{real-time} sono state introdotte delle interfacce di gestione sincrona
+dei segnali con la funzione \func{sigwait} e le sue affini. Queste funzioni
+consentono di gestire i segnali bloccando un processo fino alla avvenuta
+ricezione e disabilitando l'esecuzione asincrona di un gestore. Questo
+consente di risolvere i problemi di atomicità nella gestione degli eventi
+associati ai segnali, avendo tutto il controllo nel flusso principale del
+programma, ottenendo così una gestione simile a quella dell'I/O multiplexing,
+ma non risolve i problemi delle interazioni con quest'ultimo, perché o si
+aspetta la ricezione di un segnale o si aspetta che un file descriptor sia
+accessibile e nessuna delle rispettive funzioni consente di fare
+contemporaneamente entrambe le cose.
+
+Per risolvere questo problema nello sviluppo del kernel si è pensato di
+introdurre un meccanismo alternativo per la notifica dei segnali (ed anche di
+altri eventi generici) che, ispirandosi di nuovo alla filosofia di Unix per
+cui tutto è un file, consentisse di eseguirne la notifica con l'uso di
+opportuni file descriptor.\footnote{ovviamente si tratta di una funzionalità
+ specifica di Linux, non presente in altri sistemi unix-like, e non prevista
+ da nessuno standard.}
+
+In sostanza, come per \func{sigwait}, si può disabilitare l'esecuzione di un
+gestore di segnali e rilevare l'avvenuta ricezione leggendone la notifica da
+uno speciale file descriptor. Trattandosi in questo caso di un file descriptor
+questo potrà essere tenuto sotto osservazione con le funzioni dell'I/O
+multiplexing come quelli associati a file o socket, per cui alla fine si potrà
+attendere in contemporanea sia il segnale che la disponibilità di accesso a
+questi ultimi.
+
+La funzione che permette di abilitare la ricezione dei segnali con i
+
+
+% TODO trattare qui eventfd signalfd e timerfd introdotte con il 2.6.22
+% timerfd è stata tolta nel 2.6.23 e rifatta per bene nel 2.6.25
+% vedi: http://lwn.net/Articles/233462/
+% http://lwn.net/Articles/245533/
+% http://lwn.net/Articles/267331/
+
+
+
\section{L'accesso \textsl{asincrono} ai file}
\label{sec:file_asyncronous_access}
% LocalWords: POLLRDHUP half close pwait Gb madvise MADV ahead REMOVE tmpfs
% LocalWords: DONTFORK DOFORK shmfs preadv pwritev syscall linux loff head XFS
% LocalWords: MERGEABLE EOVERFLOW prealloca hole FALLOC KEEP stat fstat
+% LocalWords: conditions sigwait
%%% Local Variables:
projects / gapil.git / blobdiff