% Per questo segnale le cose sono complicate dal fatto che possono esserci
% molte diverse eccezioni che \texttt{SIGFPE} non distingue, mentre lo
% standard IEEE per le operazioni in virgola mobile definisce varie eccezioni
-% aritmetiche e richiede che esse siano notificate.
+% aritmetiche e richiede che esse siano notificate.
% TODO trovare altre info su SIGFPE e trattare la notifica delle eccezioni
\item[\const{SIGILL}] Il nome deriva da \textit{illegal instruction},
associati tre tempi diversi: il \textit{clock time}, l'\textit{user time} ed
il \textit{system time}. Per poterli calcolare il kernel mantiene per ciascun
processo tre diversi timer:
-\begin{itemize}
+\begin{itemize*}
\item un \textit{real-time timer} che calcola il tempo reale trascorso (che
corrisponde al \textit{clock time}). La scadenza di questo timer provoca
l'emissione di \const{SIGALRM};
system call ad esso relative (che corrisponde a quello che in
sez.~\ref{sec:sys_unix_time} abbiamo chiamato \textit{CPU time}). La scadenza
di questo timer provoca l'emissione di \const{SIGPROF}.
-\end{itemize}
+\end{itemize*}
Il timer usato da \func{alarm} è il \textit{clock time}, e corrisponde cioè al
tempo reale. La funzione come abbiamo visto è molto semplice, ma proprio per
definita direttamente nello standard POSIX.1, può a sua volta essere espressa
in termini di \func{setitimer}, come evidenziato dal manuale delle \acr{glibc}
\cite{glibc} che ne riporta la definizione mostrata in
-fig.~\ref{fig:sig_alarm_def}.
+fig.~\ref{fig:sig_alarm_def}.\footnote{questo comporta anche che non è il caso
+ di mescolare chiamate ad \func{abort} e a \func{setitimer}.}
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:sig_alarm_def}
\end{figure}
-Si deve comunque tenere presente che la precisione di queste funzioni è
-limitata da quella della frequenza del timer di sistema (che nel caso dei PC
-significa circa 10~ms). Il sistema assicura comunque che il segnale non sarà
-mai generato prima della scadenza programmata (l'arrotondamento cioè è sempre
-effettuato per eccesso).
-
-% TODO: verificare cose è successo con l'introduzione nel kernel con i timer
-% ad alta risoluzione
+Si deve comunque tenere presente che fino al kernel 2.6.16 la precisione di
+queste funzioni era limitata dalla frequenza del timer di sistema,\footnote{il
+ valore della constante \texttt{HZ}, di cui abbiamo già parlato in
+ sez.~\ref{sec:proc_hierarchy}.} in quanto le temporizzazioni erano calcolate
+in numero di interruzioni del timer (i cosiddetti ''\textit{jiffies}''), ed era
+assicurato soltanto che il segnale non sarebbe stato mai generato prima della
+scadenza programmata (l'arrotondamento cioè era effettuato per
+eccesso).\footnote{questo in realtà non è del tutto vero a causa di un bug,
+ presente fino al kernel 2.6.12, che in certe circostanze causava l'emissione
+ del segnale con un arrotondamento per difetto.} L'uso del contatore dei
+\textit{jiffies}, un intero a 32 bit, comportava inoltre l'impossibilità di
+specificare tempi molto lunghi.\footnote{superiori al valore della costante
+ \const{MAX\_SEC\_IN\_JIFFIES}, pari, nel caso di default di un valore di
+ \const{HZ} di 250, a circa 99 giorni e mezzo.} Con il cambiamento della
+rappresentazione effettuato nel kernel 2.6.16 questo problema è scomparso e
+con l'introduzione dei timer ad alta risoluzione (vedi
+sez.~\ref{sec:sig_timer_adv}) nel kernel 2.6.21 la precisione è diventata
+quella fornita dall'hardware disponibile.
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
La funzione risolve anche il problema di proseguire l'attesa dopo
l'interruzione dovuta ad un segnale; infatti in tal caso in \param{rem} viene
-restituito il tempo rimanente rispetto a quanto richiesto inizialmente, e
-basta richiamare la funzione per completare l'attesa.
+restituito il tempo rimanente rispetto a quanto richiesto
+inizialmente,\footnote{con l'eccezione, valida solo nei kernel della serie
+ 2.4, in cui, per i processi riavviati dopo essere stati fermati da un
+ segnale, il tempo passato in stato \texttt{T} non viene considerato nel
+ calcolo della rimanenza.} e basta richiamare la funzione per completare
+l'attesa.\footnote{anche qui però occorre tenere presente che i tempi sono
+ arrotondati, per cui la precisione, per quanto migliore di quella ottenibile
+ con \func{sleep}, è relativa e in caso di molte interruzioni si può avere
+ una deriva, per questo esiste la funzione \func{clock\_nanosleep} (vedi
+ sez.~\ref{sec:sig_timer_adv}) che permette di specificare un tempo assoluto
+ anziché un tempo relativo.}
Chiaramente, anche se il tempo può essere specificato con risoluzioni fino al
nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
specificato, ma prima che il processo possa tornare ad essere eseguito
-occorrerà almeno attendere il successivo giro di \itindex{scheduler} scheduler
-e cioè un tempo che a seconda dei casi può arrivare fino a 1/\const{HZ},
-(sempre che il sistema sia scarico ed il processa venga immediatamente rimesso
-in esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
+occorrerà almeno attendere la successiva interruzione del timer di sistema,
+cioè un tempo che a seconda dei casi può arrivare fino a 1/\const{HZ}, (sempre
+che il sistema sia scarico ed il processa venga immediatamente rimesso in
+esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
arrotondato al multiplo successivo di 1/\const{HZ}.
-In realtà è possibile ottenere anche pause più precise del centesimo di
-secondo usando politiche di \itindex{scheduler} scheduling real-time come
-\const{SCHED\_FIFO} o \const{SCHED\_RR}; in tal caso infatti il meccanismo di
-\itindex{scheduler} scheduling ordinario viene evitato, e si raggiungono pause
-fino ai 2~ms con precisioni del $\mu$s.
-
+Con i kernel della serie 2.4 in realtà era possibile ottenere anche pause più
+precise del centesimo di secondo usando politiche di \itindex{scheduler}
+scheduling \textit{real-time} come \const{SCHED\_FIFO} o \const{SCHED\_RR}; in
+tal caso infatti il calcolo sul numero di interruzioni del timer veniva
+evitato utilizzando direttamente un ciclo di attesa con cui si raggiungevano
+pause fino ai 2~ms con precisioni del $\mu$s. Questa estensione è stata
+rimossa con i kernel della serie 2.6, che consentono una risoluzione più alta
+del timer di sistema; inoltre a partire dal kernel 2.6.21, \func{nanosleep}
+può avvalersi del supporto dei timer ad alta risoluzione, ottenendo la massima
+precisione disponibile sull'hardware della propria macchina.
\subsection{Un esempio elementare}
versione di \func{sleep} potrebbe essere quella illustrata in
fig.~\ref{fig:sig_sleep_wrong}.
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/sleep_danger.c}
+ \end{minipage}
+ \normalsize
+ \caption{Una implementazione pericolosa di \func{sleep}.}
+ \label{fig:sig_sleep_wrong}
+\end{figure}
+
Dato che è nostra intenzione utilizzare \const{SIGALRM} il primo passo della
nostra implementazione sarà quello di installare il relativo gestore salvando
il precedente (\texttt{\small 14-17}). Si effettuerà poi una chiamata ad
(\texttt{\small 23-24}) che potrà essere diverso da zero qualora
l'interruzione di \func{pause} venisse causata da un altro segnale.
-\begin{figure}[!htb]
- \footnotesize \centering
- \begin{minipage}[c]{15cm}
- \includecodesample{listati/sleep_danger.c}
- \end{minipage}
- \normalsize
- \caption{Una implementazione pericolosa di \func{sleep}.}
- \label{fig:sig_sleep_wrong}
-\end{figure}
-
Questo codice però, a parte il non gestire il caso in cui si è avuta una
precedente chiamata a \func{alarm} (che si è tralasciato per brevità),
presenta una pericolosa \itindex{race~condition} \textit{race condition}.
grado di ricevere informazioni più dettagliate dal sistema, attraverso la
struttura \struct{siginfo\_t}, riportata in fig.~\ref{fig:sig_siginfo_t}.
+Installando un gestore di tipo \var{sa\_sigaction} diventa allora possibile
+accedere alle informazioni restituite attraverso il puntatore a questa
+struttura. Tutti i segnali impostano i campi \var{si\_signo}, che riporta il
+numero del segnale ricevuto, \var{si\_errno}, che riporta, quando diverso da
+zero, il codice dell'errore associato al segnale, e \var{si\_code}, che viene
+usato dal kernel per specificare maggiori dettagli riguardo l'evento che ha
+causato l'emissione del segnale.
+
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
\label{fig:sig_siginfo_t}
\end{figure}
-Installando un gestore di tipo \var{sa\_sigaction} diventa allora possibile
-accedere alle informazioni restituite attraverso il puntatore a questa
-struttura. Tutti i segnali impostano i campi \var{si\_signo}, che riporta il
-numero del segnale ricevuto, \var{si\_errno}, che riporta, quando diverso da
-zero, il codice dell'errore associato al segnale, e \var{si\_code}, che viene
-usato dal kernel per specificare maggiori dettagli riguardo l'evento che ha
-causato l'emissione del segnale.
-
In generale \var{si\_code} contiene, per i segnali generici, per quelli
real-time e per tutti quelli inviati tramite da un processo con \func{kill} o
affini, le informazioni circa l'origine del segnale stesso, ad esempio se
possibili si trovano in \file{bits/siginfo.h}.} ed i valori possibili in
questo caso sono riportati in tab.~\ref{tab:sig_sa_code_generic}.
+Nel caso di alcuni segnali però il valore di \var{si\_code} viene usato per
+fornire una informazione specifica relativa alle motivazioni della ricezione
+dello stesso; ad esempio i vari segnali di errore (\const{SIGILL},
+\const{SIGFPE}, \const{SIGSEGV} e \const{SIGBUS}) lo usano per fornire
+maggiori dettagli riguardo l'errore, come il tipo di errore aritmetico, di
+istruzione illecita o di violazione di memoria; mentre alcuni segnali di
+controllo (\const{SIGCHLD}, \const{SIGTRAP} e \const{SIGPOLL}) forniscono
+altre informazioni specifiche.
+
\begin{table}[!htb]
\footnotesize
\centering
\label{tab:sig_sa_code_generic}
\end{table}
-\footnotetext[17]{introdotto con il kernel 2.6.6.}
+\footnotetext[24]{introdotto con il kernel 2.6.6.}
\footnotetext{introdotto con il kernel 2.4.19.}
-Nel caso di alcuni segnali però il valore di \var{si\_code} viene usato per
-fornire una informazione specifica relativa alle motivazioni della ricezione
-dello stesso; ad esempio i vari segnali di errore (\const{SIGILL},
-\const{SIGFPE}, \const{SIGSEGV} e \const{SIGBUS}) lo usano per fornire
-maggiori dettagli riguardo l'errore, come il tipo di errore aritmetico, di
-istruzione illecita o di violazione di memoria; mentre alcuni segnali di
-controllo (\const{SIGCHLD}, \const{SIGTRAP} e \const{SIGPOLL}) forniscono
-altre informazioni specifiche.
-
In questo caso il valore del campo \var{si\_code} deve essere verificato nei
confronti delle diverse costanti previste per ciascuno di detti
segnali;\footnote{dato che si tratta di una costante, e non di una maschera
segnali real-time (vedi sez.~\ref{sec:sig_real_time}) inviati tramite
\func{kill} avvalorano \var{si\_pid} e \var{si\_uid} coi valori corrispondenti
al processo che ha emesso il segnale, \const{SIGCHLD} avvalora anche i campi
-\const{si\_status}, \const{si\_utime} and \const{si\_stime} che indicano
+\const{si\_status}, \const{si\_utime} e \const{si\_stime} che indicano
rispettivamente lo stato di uscita, l'\textit{user time} e il \textit{system
time} (vedi sez.~\ref{sec:sys_cpu_times}) usati dal processo;
\const{SIGILL}, \const{SIGFPE}, \const{SIGSEGV} e \const{SIGBUS} avvalorano
\caption{Una implementazione completa di \func{sleep}.}
\label{fig:sig_sleep_ok}
\end{figure}
-
+
Per evitare i problemi di interferenza con gli altri segnali in questo caso
non si è usato l'approccio di fig.~\ref{fig:sig_sleep_incomplete} evitando
l'uso di \func{longjmp}. Come in precedenza il gestore (\texttt{\small 27-30})
assolutamente generale e può essere applicato a qualunque altra situazione in
cui si deve attendere per un segnale, i passi sono sempre i seguenti:
\begin{enumerate*}
-\item Leggere la maschera dei segnali corrente e bloccare il segnale voluto
+\item leggere la maschera dei segnali corrente e bloccare il segnale voluto
con \func{sigprocmask};
-\item Mandare il processo in attesa con \func{sigsuspend} abilitando la
+\item mandare il processo in attesa con \func{sigsuspend} abilitando la
ricezione del segnale voluto;
-\item Ripristinare la maschera dei segnali originaria.
+\item ripristinare la maschera dei segnali originaria.
\end{enumerate*}
Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi
riabilitarla immediatamente dopo, in questo modo si evita il
solo durante l'esecuzione di un gestore. L'uso di uno \textit{stack}
alternativo è del tutto trasparente ai gestori, occorre però seguire una certa
procedura:
-\begin{enumerate}
-\item Allocare un'area di memoria di dimensione sufficiente da usare come
+\begin{enumerate*}
+\item allocare un'area di memoria di dimensione sufficiente da usare come
\textit{stack} alternativo;
-\item Usare la funzione \func{sigaltstack} per rendere noto al sistema
+\item usare la funzione \func{sigaltstack} per rendere noto al sistema
l'esistenza e la locazione dello \textit{stack} alternativo;
-\item Quando si installa un gestore occorre usare \func{sigaction}
+\item quando si installa un gestore occorre usare \func{sigaction}
specificando il flag \const{SA\_ONSTACK} (vedi tab.~\ref{tab:sig_sa_flag})
per dire al sistema di usare lo \textit{stack} alternativo durante
l'esecuzione del gestore.
-\end{enumerate}
+\end{enumerate*}
In genere il primo passo viene effettuato allocando un'opportuna area di
memoria con \code{malloc}; in \file{signal.h} sono definite due costanti,
Resta quindi il problema di cosa succede alla maschera dei segnali quando si
esce da un gestore usando questa funzione. Il comportamento dipende
-dall'implementazione; in particolare BSD prevede che sia ripristinata la
-maschera dei segnali precedente l'invocazione, come per un normale ritorno,
-mentre System V no.
+dall'implementazione; in particolare la semantica usata da BSD prevede che sia
+ripristinata la maschera dei segnali precedente l'invocazione, come per un
+normale ritorno, mentre quella usata da System V no.
Lo standard POSIX.1 non specifica questo comportamento per \func{setjmp} e
\func{longjmp}, ed il comportamento delle \acr{glibc} dipende da quale delle
\index{funzioni!sicure|(}
Il concetto è comunque più generale e porta ad una distinzione fra quelle che
-che POSIX chiama \textsl{funzioni insicure} (\textit{n'Usane function}) e
+che POSIX chiama \textsl{funzioni insicure} (\textit{unsafe function}) e
\textsl{funzioni sicure} (\textit{safe function}); quando un segnale
interrompe una funzione insicura ed il gestore chiama al suo interno una
funzione insicura il sistema può dare luogo ad un comportamento indefinito.
\label{sec:sig_real_time}
Lo standard POSIX.1b, nel definire una serie di nuove interfacce per i servizi
-real-time, ha introdotto una estensione del modello classico dei segnali che
-presenta dei significativi miglioramenti,\footnote{questa estensione è stata
- introdotta in Linux a partire dal kernel 2.1.43(?), e dalle \acr{glibc}
- 2.1(?).} in particolare sono stati superati tre limiti fondamentali dei
-segnali classici:
+\textit{real-time}, ha introdotto una estensione del modello classico dei
+segnali che presenta dei significativi miglioramenti,\footnote{questa
+ estensione è stata introdotta in Linux a partire dal kernel 2.1.43, e dalle
+ \acr{glibc} 2.1.} in particolare sono stati superati tre limiti fondamentali
+dei segnali classici:
\begin{basedescript}{\desclabelwidth{1cm}\desclabelstyle{\nextlinelabel}}
\item[I segnali non sono accumulati]
se più segnali vengono generati prima dell'esecuzione di un gestore
certi segnali ha la precedenza rispetto ad altri.
\end{basedescript}
-Per poter superare queste limitazioni lo standard ha introdotto delle nuove
-caratteristiche, che sono state associate ad una nuova classe di segnali, che
-vengono chiamati \textsl{segnali real-time}, in particolare le funzionalità
-aggiunte sono:
+Per poter superare queste limitazioni lo standard POSIX.1b ha introdotto delle
+nuove caratteristiche, che sono state associate ad una nuova classe di
+segnali, che vengono chiamati \textsl{segnali real-time}, in particolare le
+funzionalità aggiunte sono:
\begin{enumerate}
\item i segnali sono inseriti in una coda che permette di consegnare istanze
\var{sa\_sigaction}.
\end{enumerate}
-Queste nuove funzionalità (eccetto l'ultima, che, come vedremo, è parzialmente
-disponibile anche con i segnali ordinari) si applicano solo ai nuovi segnali
-real-time; questi ultimi sono accessibili in un range di valori specificati
-dalle due macro \const{SIGRTMIN} e \const{SIGRTMAX},\footnote{in Linux di
- solito (cioè sulla piattaforma i386) il primo valore è 33, ed il secondo
- \code{\_NSIG-1}, che di norma è 64, per un totale di 32 segnali disponibili,
- contro gli almeno 8 richiesti da POSIX.1b.} che specificano il numero minimo
-e massimo associato ad un segnale real-time.
+Tutte queste nuove funzionalità eccetto l'ultima, che, come illustrato in
+sez.~\ref{sec:sig_sigaction}, è disponibile anche con i segnali ordinari, si
+applicano solo ai nuovi segnali \textit{real-time}; questi ultimi sono
+accessibili in un intervallo di valori specificati dalle due costanti
+\const{SIGRTMIN} e \const{SIGRTMAX},\footnote{in Linux di solito (cioè sulla
+ piattaforma i386) il primo valore è 33, ed il secondo \code{\_NSIG-1}, che
+ di norma è 64, per un totale di 32 segnali disponibili, contro gli almeno 8
+ richiesti da POSIX.1b.} che specificano il numero minimo e massimo associato
+ad un segnale real-time.
+
+% TODO rivedere secondo man 7 signal con le informazioni aggiornate sul numero
+% di segnali real-time disponibili
I segnali con un numero più basso hanno una priorità maggiore e vengono
-consegnati per primi, inoltre i segnali real-time non possono interrompere
-l'esecuzione di un gestore di un segnale a priorità più alta; la loro azione
-predefinita è quella di terminare il programma. I segnali ordinari hanno
-tutti la stessa priorità, che è più alta di quella di qualunque segnale
-real-time.
+consegnati per primi, inoltre i segnali \textit{real-time} non possono
+interrompere l'esecuzione di un gestore di un segnale a priorità più alta; la
+loro azione predefinita è quella di terminare il programma. I segnali
+ordinari hanno tutti la stessa priorità, che è più alta di quella di qualunque
+segnale \textit{real-time}.\footnote{lo standard non definisce niente al
+ riguardo ma Linux, come molte altre implementazioni, adotta questa
+ politica.}
+
Si tenga presente che questi nuovi segnali non sono associati a nessun evento
specifico, a meno di non utilizzarli in meccanismi di notifica come quelli per
In particolare i campi utilizzati dai segnali real-time sono \var{si\_pid} e
\var{si\_uid} in cui vengono memorizzati rispettivamente il \acr{pid} e
l'user-ID effettivo del processo che ha inviato il segnale, mentre per la
-restituzione dei dati viene usato il campo \var{si\_value}.
+restituzione dei dati viene usato il campo \var{si\_value}.
Questo è una \ctyp{union} di tipo \struct{sigval\_t} (la sua definizione è in
fig.~\ref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico,
se usata nella forma \var{sival\_int}, o un indirizzo, se usata nella forma
\var{sival\_ptr}. L'unione viene usata dai segnali real-time e da vari
meccanismi di notifica\footnote{un campo di tipo \struct{sigval\_t} è presente
- anche nella struttura \struct{sigevent} che viene usata dai meccanismi di
- notifica come quelli per l'I/O asincrono (vedi
- sez.~\ref{sec:file_asyncronous_io}) o le code di messaggi POSIX (vedi
- sez.~\ref{sec:ipc_posix_mq}).} per restituire dati al gestore del segnale; in
-alcune definizioni essa viene identificata anche come \code{union sigval}.
+ anche nella struttura \struct{sigevent} (definita in
+ fig.~\ref{fig:file_sigevent}) che viene usata dai meccanismi di notifica
+ come quelli per l'I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io}) o
+ le code di messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}).} per
+restituire dati al gestore del segnale; in alcune definizioni essa viene
+identificata anche come \code{union sigval}.
\begin{figure}[!htb]
\footnotesize \centering
\end{figure}
A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
-inviare segnali real-time, poiché non è in grado di fornire alcun valore
-per \struct{sigval\_t}; per questo motivo lo standard ha previsto una nuova
-funzione, \funcd{sigqueue}, il cui prototipo è:
+inviare segnali \textit{real-time}, poiché non è in grado di fornire alcun
+valore per \struct{sigval\_t}; per questo motivo lo standard ha previsto una
+nuova funzione, \funcd{sigqueue}, il cui prototipo è:
\begin{prototype}{signal.h}
{int sigqueue(pid\_t pid, int signo, const sigval\_t value)}
% LocalWords: sysconf tcdrain tcflow tcflush tcgetattr tcgetgrp tcsendbreak
% LocalWords: tcsetattr tcsetpgrp getoverrun times umask uname unlink utime
% LocalWords: write sival SIVGTALRM NOCLDWAIT MESGQ ASYNCIO TKILL tkill tgkill
+% LocalWords: ILL ILLOPC ILLOPN ILLADR ILLTRP PRVOPC PRVREG COPROC BADSTK FPE
+% LocalWords: INTDIV INTOVF FLTDIV FLTOVF FLTUND underflow FLTRES FLTINV SEGV
+% LocalWords: FLTSUB MAPERR ACCERR ADRALN ADRERR OBJERR BRKPT CLD EXITED MSG
+% LocalWords: KILLED DUMPED TRAPPED STOPPED CONTINUED PRI HUP SigFunc jiffies
+% LocalWords: SEC
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
-% LocalWords: ILL ILLOPC ILLOPN ILLADR ILLTRP PRVOPC PRVREG COPROC BADSTK FPE
-% LocalWords: INTDIV INTOVF FLTDIV FLTOVF FLTUND underflow FLTRES FLTINV SEGV
-% LocalWords: FLTSUB MAPERR ACCERR ADRALN ADRERR OBJERR BRKPT CLD EXITED MSG
-% LocalWords: KILLED DUMPED TRAPPED STOPPED CONTINUED PRI HUP SigFunc
projects / gapil.git / commitdiff