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}
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
\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
\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.
\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.
projects / gapil.git / blobdiff