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
+unix-like, porti a notevoli 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
+\textit{race condition} sono state introdotte 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
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
+nel fatto che questa modalità di funzionamento cozza con altre interfacce di
+programmazione previste dal sistema in cui si opera in maniera
+\textsl{sincrona}, come quelle dell'I/O multiplexing appena illustrate.
+
+In questo tipo di interfacce infatti ci si aspetta che il processo gestisca
+gli eventi a cui vuole rispondere in maniera sincrona generando le opportune
+risposte, mentre con l'arrivo di un segnale si possono avere interruzioni
+asincrone in qualunque momento. Questo comporta la necessità di dover
+gestire, quando si deve tener conto di entrambi i tipi di eventi, le
+interruzioni delle funzioni di attesa sincrone, 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
+ fossero per i segnali non ci sarebbe da doversi preoccupare, fintanto che si
+ effettuano operazioni all'interno di un processo, della non atomicità 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.
+\textit{real-time} sono state introdotte anche 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 rispetto al resto
+del programma del gestore del segnale. 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
+introdurre un meccanismo alternativo alla notifica dei segnali (esteso anche
+ad altri eventi generici) che, ispirandosi di nuovo alla filosofia di Unix per
+cui tutto è un file, consentisse di eseguire 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.
+gestore in occasione dell'arrivo di un segnale, e rilevarne l'avvenuta
+ricezione leggendone la notifica tramite l'uso di uno speciale file
+descriptor. Trattandosi di un file descriptor questo potrà essere tenuto sotto
+osservazione con le ordinarie funzioni dell'I/O multiplexing (vale a dire con
+le solite \func{select}, \func{poll} e \funcd{epoll\_wait}) allo stesso modo
+di quelli associati a file o socket, per cui alla fine si potrà attendere in
+contemporanea sia l'arrivo del segnale che la disponibilità di accesso ai dati
+relativi a questi ultimi.
+
+La funzione che permette di abilitare la ricezione dei segnali tramite file
+descriptor è \funcd{signalfd}, il cui prototipo è:
+\begin{prototype}{sys/signalfd.h}
+ {int signalfd(int fd, const sigset\_t *mask, int flags)}
-La funzione che permette di abilitare la ricezione dei segnali con i
+ Attende che uno dei file descriptor osservati sia pronto, mascherando i
+ segnali.
+ \bodydesc{La funzione restituisce il numero di file descriptor pronti in
+ caso di successo o $-1$ in caso di errore, nel qual caso \var{errno}
+ assumerà uno dei valori già visti con \funcd{epoll\_wait}.
+}
+\end{prototype}
% 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
projects / gapil.git / commitdiff