\label{sec:sig_signalfd_eventfd}
I segnali sono uno dei meccanismi classici, presenti da sempre nei sistemi
-unix-like, per effettuare notifiche ai processi, la loro interfaccia però,
-richiedendo l'esecuzione asincrona di una funzione di gestione al di fuori del
-flusso di esecuzione principale del processo, si è dimostrata quasi subito
-assai problematica.
-
-Oltre ai limiti relativi a cosa si può fare nel gestore di segnali (quelli
-illustrati in sez.~\ref{sec:sig_signal_handler}), ed ai problemi relativi alla
-interruzione delle system call bloccanti, c'è un problema più generale
-consistente nel fatto che questa modalità di funzionamento cozza con le
-interfacce di programmazione sincrona, in cui ci si aspetta che ci sia un solo
-processo che gestisce gli eventi e genera delle risposte, mentre con l'arrivo
-di un segnale ci si trova alla possibilità di interruzioni asincrone da
-gestire e nella necessità di evitare \textit{race conditions}.
+unix-like, per effettuare notifiche ai processi, la loro interfaccia di
+programmazione però, che comporta l'esecuzione di una funzione di gestione in
+maniera asincrona e totalmente scorrelata dall'ordinario flusso di esecuzione
+del processo, si è dimostrata quasi subito assai problematica.
+
+Oltre ai limiti relativi ai limiti sul cosa si può fare nel gestore di segnali
+(quelli illustrati in sez.~\ref{sec:sig_signal_handler}), c'è un problema più
+generale consistente nel fatto che questa modalità di funzionamento cozza con
+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 system call bloccanti.
+
+In questo caso infatti si aspetta che il processo gestisca gli eventi (che
+causano l'uscita dalla 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à delle stesse (si ricordi quanto detto in
+ sez.~\ref{sec:proc_atom_oper}).}
In particolare, come vedremo in sez.~\ref{sec:file_select}, i segnali hanno
una pessima interazione con le funzioni di gestione dell'I/O multiplexing, che
costituiscono un meccanismo efficiente per gestire in maniera sincrona
l'accesso a più file o socket in cui il processo si blocca fintanto che non ci
-sono dati da leggere o scrivere.\footnote{per la trattazione dettagliata del
- significato e dei vantaggi dell'I/O multiplexing si rimanda a
- sez.~\ref{sec:file_multiplexing}.}
-
-Abbiamo visto in sez.~\ref{sec:sig_real_time} che con i segnali
+sono dati da leggere o scrivere su uno qualunque fra i file descriptor ad essi
+associati.\footnote{per la trattazione dettagliata del significato e dei
+ vantaggi dell'I/O multiplexing si rimanda a
+ sez.~\ref{sec:file_multiplexing}, per la trattazione dei problemi
+ dell'interazione coi segnali si veda quanto illustrato in
+ sez.~\ref{sec:file_select} riguardo la necessità di \func{pselect}.}
+
+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 \func{sigwait} e affini, che consentono di gestire i segnali
-in modalità sincrona, bloccando un processo fino alla ricezione di un segnale
-(e disabilitando l'esecuzione asincrona di un gestore). Questo però non
-risolve i problemi di interazioni con le funzioni I/O multiplexing per cui
-nello sviluppo del kernel si è pensato di introdurre un meccanismo alternativo
-per la notifica dei segnali (ed anche di eventi generici) basato direttamente
-sull'uso di file descriptor.
+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,
+però non risolve i problemi dell'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 relative 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 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 emissione di un
+segnale leggendone la notifica da un file descriptor speciale; ma essendo
+questo comunque un file descriptor 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.
projects / gapil.git / commitdiff