From: Simone Piccardi Date: Mon, 20 Sep 2010 08:46:03 +0000 (+0000) Subject: Piccole modifiche X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=0bcf5c7d8d90342067fe6cb28045993bf6c7f207;p=gapil.git Piccole modifiche --- diff --git a/signal.tex b/signal.tex index addf4f0..177555d 100644 --- 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.