From: Simone Piccardi Date: Wed, 29 Sep 2010 11:58:03 +0000 (+0000) Subject: Piccole modifiche X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=9eadbd19c07e0da7b9ead4e8aff628b94cd10346;p=gapil.git Piccole modifiche --- diff --git a/signal.tex b/signal.tex index 7367c63..fd19102 100644 --- a/signal.tex +++ b/signal.tex @@ -3386,37 +3386,66 @@ notifica di una scadenza, il comportamento del sistema \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.