X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;ds=sidebyside;f=fileadv.tex;h=87e9690f58f4a282f361a53e979352c2471edeb7;hb=0419cb467b02a96b30c9b8e98731a16d792b6e03;hp=add3a015630bd126dc4a2db6b74e1f73e78b54ea;hpb=6239c73063d5934b7b74b74584c154d9f07ecd32;p=gapil.git

diff --git a/fileadv.tex b/fileadv.tex
index add3a01..87e9690 100644
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -1811,6 +1811,81 @@ che utilizza questa interfaccia in sez.~\ref{sec:TCP_sock_multiplexing}.
 \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}
 
@@ -4821,6 +4896,7 @@ livello di kernel.
 % 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: