\const{SIGTRAP} &SL & C & Trappole per un Trace/breakpoint. \\
\const{SIGURG} &SLB& B & Ricezione di una \textit{urgent condition} su
un socket. \\
- \const{SIGVTALRM}&SLB& A & Virtual alarm clock. \\
+ \const{SIGVTALRM}&SLB& A & Timer di esecuzione scaduto. \\
\const{SIGXCPU} &SLB& C & Ecceduto il limite sul tempo di CPU. \\
\const{SIGXFSZ} &SLB& C & Ecceduto il limite sulla dimensione dei file. \\
\const{SIGIOT} &L & C & IOT trap. Sinonimo di \const{SIGABRT}. \\
\subsection{I segnali di allarme}
\label{sec:sig_alarm}
-Questi segnali sono generati dalla scadenza di un timer. Il loro comportamento
-predefinito è quello di causare la terminazione del programma, ma con questi
-segnali la scelta predefinita è irrilevante, in quanto il loro uso presuppone
-sempre la necessità di un gestore. Questi segnali sono:
+Questi segnali sono generati dalla scadenza di un timer (vedi
+sez.~\ref{sec:sig_alarm_abort}). Il loro comportamento predefinito è quello di
+causare la terminazione del programma, ma con questi segnali la scelta
+predefinita è irrilevante, in quanto il loro uso presuppone sempre la
+necessità di un gestore. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{SIGALRM}] Il nome sta per \textit{alarm}. Segnale la scadenza di
un timer misurato sul tempo reale o sull'orologio di sistema. È normalmente
usato dalla funzione \func{alarm}.
-\item[\const{SIGVTALRM}] Il nome sta per \textit{virtual alarm}. È analogo al
+\item[\const{SIVGTALRM}] Il nome sta per \textit{virtual alarm}. È analogo al
precedente ma segnala la scadenza di un timer sul tempo di CPU usato dal
processo.
mai generato prima della scadenza programmata (l'arrotondamento cioè è sempre
effettuato per eccesso).
+% TODO: verificare cose è successo con l'introduzione nel kernel degli htrimer
+
Una seconda causa di potenziali ritardi è che il segnale viene generato alla
scadenza del timer, ma poi deve essere consegnato al processo; se quest'ultimo
è attivo (questo è sempre vero per \const{ITIMER\_VIRT}) la consegna è
stato consegnato; in questo caso, per il comportamento dei segnali descritto
in sez.~\ref{sec:sig_sigchld}, un solo segnale sarà consegnato.
-
Dato che sia \func{alarm} che \func{setitimer} non consentono di leggere il
valore corrente di un timer senza modificarlo, è possibile usare la funzione
\funcd{getitimer}, il cui prototipo è:
Questo è il tipico esempio di caso, già citato in
sez.~\ref{sec:proc_race_cond}, in cui si genera una \itindex{race~condition}
\textit{race condition}; infatti, in una situazione in cui un segnale è già
-arrivato (e \var{flag} è già ad 1) se un altro segnale segnale arriva
-immediatamente dopo l'esecuzione del controllo (\texttt{\small 6}) ma prima
-della cancellazione del flag (\texttt{\small 7}), la sua occorrenza sarà
-perduta.
+arrivato (e \var{flag} è già ad 1) se un altro segnale arriva immediatamente
+dopo l'esecuzione del controllo (\texttt{\small 6}) ma prima della
+cancellazione del flag (\texttt{\small 7}), la sua occorrenza sarà perduta.
Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono
delle funzioni più sofisticate di quelle finora illustrate, queste hanno la
\subsection{La gestione avanzata delle temporizzazioni}
\label{sec:sig_timer_adv}
-
+% TODO trattare i Posix timer, e le fuzioni:
+% clock_getres clock_gettime clock_settime (vedi man page)
+% timer_getoverrun, timer_gettime, timer_settime, timer_create, timer_delete
\subsection{Le interfacce per la notifica attraverso i file descriptor}
\label{sec:sig_signalfd_eventfd}
-% TODO trattare qui eventfd signalfd e timerfd introdotte con il 2.6.22
+% TODO trattare qui eventfd signalfd e timerfd introdotte con il 2.6.22
+% timerfd è stata tolta nel 2.6.23 e rifatta per bene nel 2.6.25
% vedi: http://lwn.net/Articles/233462/
% http://lwn.net/Articles/245533/
+% http://lwn.net/Articles/267331/
+
+
% LocalWords: kernel POSIX timer shell control ctrl kill raise signal handler