\var{sigev\_value}, se diverso da \val{NULL} il
\textit{thread} viene creato con gli attributi
specificati da \var{sigev\_notify\_attribute}.\\
+ \footnotemark
\const{SIGEV\_THREAD\_ID}& Invia la notifica come segnale (con le stesse
modalità di \const{SIGEV\_SIGNAL}) che però viene
recapitato al \textit{thread} indicato dal campo
\label{tab:sigevent_sigev_notify}
\end{table}
+\footnotetext{questa funzionalità è considerata un esempio di pessima
+ implementazione di una interfaccia, richiesta dallo standard POSIX, ma da
+ evitare totalmente, causa la possibilità di creare disservizi generando una
+ gran quantità di processi, tanto che ne è stata richiesta addirittura la
+ rimozione.}
+
Nel caso di \func{timer\_create} occorrerà passare alla funzione come secondo
argomento l'indirizzo di una di queste strutture per indicare le modalità con
cui si vuole essere notificati della scadenza del timer, se non si specifica
\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 / blobdiff