Piccole modifiche

diff --git a/signal.tex b/signal.tex
index addf4f0be7d183cab130f151cad31f02320bb95a..177555d272f2a7d13a1e15019b3969916185d886 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -865,6 +865,9 @@ sez.~\ref{sec:sig_sigaction}). 
 interruzione nel mezzo di un trasferimento parziale di dati, le system call
 ritornano sempre indicando i byte trasferiti.
 
+% TODO: alcune syscall danno EINTR anche se il segnale è installato con
+% SA_RESTART, vedi signal(7)
+
 
 \subsection{La funzione \func{signal}}
 \label{sec:sig_signal}
@@ -2670,6 +2673,9 @@ sostituito dalla risorsa \const{RLIMIT\_SIGPENDING} associata al singolo
 utente, che può essere modificata con \func{setrlimit} come illustrato in
 sez.~\ref{sec:sys_resource_limit}.
 
+% TODO: spostare insieme a signalfd e affini, meccanismo di notifica sincrona
+% dei segnali (da capire se è il caso di farlo)
+
 Lo standard POSIX.1b definisce inoltre delle nuove funzioni che permettono di
 gestire l'attesa di segnali specifici su una coda, esse servono in particolar
 modo nel caso dei \itindex{thread} \textit{thread}, in cui si possono usare i
@@ -3363,9 +3369,9 @@ cui prototipo 
 \end{functions}
 
 La funzione elimina il timer identificato da \param{timerid}, disarmandolo se
-questo era stato attivato. Nel caso poco probabile, ma comunque possibile, che
+questo era stato attivato. Nel caso, poco probabile ma comunque possibile, che
 un timer venga cancellato prima della ricezione del segnale pendente per la
-notifica di una scadenza, il comportamento del sistema è indefinito. 
+notifica di una scadenza, il comportamento del sistema è indefinito.
 
 
 
@@ -3373,15 +3379,37 @@ 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ò si è
-dimostrata quasi subito poco azzeccata, in particolare per i problemi che si
-vengono a creare con le funzioni di gestione dell'I/O multiplexing (vedi
-sez.~\ref{sec:file_multiplexing}).\footnote{i temi trattati in questa sezione
-  presuppongono la conoscenza dell'I/O multiplexing si consiglia pertanto una
-  lettura di sez.~\ref{sec:file_multiplexing} qualora non si conosca
-  l'argomento. } Per questo motivo 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.
+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}.
+
+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
+\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.