X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=2f5516b0fe4f563df3c5cf235e6116d957d0534c;hp=4463fb009b9298f7d39feeeecbcae03fd2131174;hb=5afbcf1d6a84ab2a527859d8fd05b75a31e39736;hpb=04a547df13e4c672d95e1060e1ada9ae2e1fcb2f diff --git a/signal.tex b/signal.tex index 4463fb0..2f5516b 100644 --- a/signal.tex +++ b/signal.tex @@ -1048,7 +1048,7 @@ quanto non sia la versione originaria, che di norma è definita come: questa infatti, per la poca chiarezza della sintassi del C quando si vanno a trattare puntatori a funzioni, è molto meno comprensibile. Da un confronto con il precedente prototipo si può dedurre la definizione di -\type{sighandler\_t} che è: +\typed{sighandler\_t} che è: \includecodesnip{listati/sighandler_t.c} e cioè un puntatore ad una funzione \ctyp{void} (cioè senza valore di ritorno) e che prende un argomento di tipo \ctyp{int}. Si noti come si devono usare le @@ -1097,8 +1097,8 @@ per i motivi visti in sez.~\ref{sec:sig_semantics}, può essere ottenuto chiamando \funcm{sysv\_signal}, una volta che si sia definita la macro \macro{\_XOPEN\_SOURCE}. In generale, per evitare questi problemi, l'uso di \func{signal}, che tra l'altro ha un comportamento indefinito in caso di -processo \itindex{thread} multi-\textit{thread}, è da evitare: tutti i nuovi -programmi devono usare \func{sigaction}. +processo multi-\textit{thread}, è da evitare: tutti i nuovi programmi devono +usare \func{sigaction}. È da tenere presente che, seguendo lo standard POSIX, il comportamento di un processo che ignora i segnali \signal{SIGFPE}, \signal{SIGILL}, o @@ -1437,22 +1437,21 @@ 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, determinato dal valore della costante \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 \itindex{jiffies} -``\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 \itindex{jiffies} \textit{jiffies}, un intero a 32 bit -nella maggior parte dei casi, comportava inoltre l'impossibilità di -specificare tempi molto lunghi. 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. +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 nella maggior +parte dei casi, comportava inoltre l'impossibilità di specificare tempi molto +lunghi. 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 @@ -1466,9 +1465,8 @@ in cui un timer scade prima che il segnale di una precedente scadenza sia stato consegnato. In questo caso, per il comportamento dei segnali descritto in sez.~\ref{sec:sig_sigchld}, un solo segnale sarà consegnato. Per questo oggi l'uso di questa funzione è deprecato a favore degli -\itindex{High~Resolution~Timer~(HRT)} \textit{high-resolution timer} e della -cosiddetta \itindex{POSIX~Timer~API} \textit{POSIX Timer API}, che tratteremo -in sez.~\ref{sec:sig_timer_adv}. +\textit{high-resolution timer} e della cosiddetta \itindex{POSIX~Timer~API} +\textit{POSIX Timer API}, che tratteremo in sez.~\ref{sec:sig_timer_adv}. Dato che sia \func{alarm} che \func{setitimer} non consentono di leggere il valore corrente di un timer senza modificarlo, è possibile usare la funzione @@ -2758,7 +2756,7 @@ mentre per la restituzione dei dati viene usato il campo \var{si\_value}. \end{minipage} \normalsize \caption{La definizione dell'unione \structd{sigval}, definita anche come - tipo \type{sigval\_t}.} + tipo \typed{sigval\_t}.} \label{fig:sig_sigval} \end{figure} @@ -2835,9 +2833,9 @@ sez.~\ref{sec:sys_resource_limit}. Lo standard POSIX.1b definisce inoltre delle nuove funzioni di sistema 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 segnali \textit{real-time} come meccanismi di comunicazione -elementare; la prima di queste è \funcd{sigwait}, il cui prototipo è: +in particolar modo nel caso dei \textit{thread}, in cui si possono usare i +segnali \textit{real-time} come meccanismi di comunicazione elementare; la +prima di queste è \funcd{sigwait}, il cui prototipo è: \begin{funcproto}{ \fhead{signal.h} @@ -2872,7 +2870,7 @@ consegnato che essere ricevuto da \func{sigwait}, il tutto in maniera non prevedibile. Lo standard POSIX.1b definisce altre due funzioni di sistema, anch'esse usate -prevalentemente con i \itindex{thread} \textit{thread}; \funcd{sigwaitinfo} e +prevalentemente con i \textit{thread}; \funcd{sigwaitinfo} e \funcd{sigtimedwait}, i relativi prototipi sono: \begin{funcproto}{ @@ -2941,12 +2939,12 @@ dalla frequenza dello stesso che si ricordi, come già illustrato in sez.~\ref{sec:proc_hierarchy}, è data dal valore della costante \texttt{HZ}. I contatori usati per il calcolo dei tempi infatti erano basati sul numero di -\itindex{jiffies} \textit{jiffies} che vengono incrementati ad ogni -\textit{clock tick} del timer di sistema, il che comportava anche, come -accennato in sez.~\ref{sec:sig_alarm_abort} per \func{setitimer}, problemi per -il massimo periodo di tempo copribile da alcuni di questi orologi, come quelli -associati al \textit{process time} almeno fino a quando, con il kernel 2.6.16, -non è stato rimosso il limite di un valore a 32 bit per i \textit{jiffies}. +\textit{jiffies} che vengono incrementati ad ogni \textit{clock tick} del +timer di sistema, il che comportava anche, come accennato in +sez.~\ref{sec:sig_alarm_abort} per \func{setitimer}, problemi per il massimo +periodo di tempo copribile da alcuni di questi orologi, come quelli associati +al \textit{process time} almeno fino a quando, con il kernel 2.6.16, non è +stato rimosso il limite di un valore a 32 bit per i \textit{jiffies}. \itindbeg{POSIX~Timer~API} @@ -3012,12 +3010,10 @@ tab.~\ref{tab:sig_timer_clockid_types}. sez.~\ref{sec:sys_cpu_times}, nel totale di \textit{system time} e \textit{user time}) comprensivo di tutto il tempo di CPU usato - da eventuali \itindex{thread} - \textit{thread}.\\ + da eventuali \textit{thread}.\\ \const{CLOCK\_THREAD\_CPUTIME\_ID}& Contatore del tempo di CPU (\textit{user time} e \textit{system time}) - usato da un singolo \itindex{thread} - \textit{thread}.\\ + usato da un singolo \textit{thread}.\\ \hline \const{CLOCK\_MONOTONIC\_RAW}&Simile al precedente, ma non subisce gli aggiustamenti dovuti all'uso di NTP (viene @@ -3045,7 +3041,7 @@ tab.~\ref{tab:sig_timer_clockid_types}. % \const{} & .\\ \hline \end{tabular} - \caption{Valori possibili per una variabile di tipo \type{clockid\_t} + \caption{Valori possibili per una variabile di tipo \typed{clockid\_t} usata per indicare a quale tipo di orologio si vuole fare riferimento.} \label{tab:sig_timer_clockid_types} \end{table} @@ -3347,8 +3343,8 @@ effettuata. Diventa così possibile indicare l'uso di un segnale o l'esecuzione è in fig.~\ref{fig:sig_sigval}) come valore del campo \var{si\_value} di \struct{siginfo\_t}.\\ \const{SIGEV\_THREAD} & La notifica viene effettuata creando un nuovo - \itindex{thread} \textit{thread} che esegue la - funzione di notifica specificata da + \textit{thread} che esegue la funzione di + notifica specificata da \var{sigev\_notify\_function} con argomento \var{sigev\_value}. Se questo è diverso da \val{NULL}, il \textit{thread} viene creato con @@ -3385,7 +3381,7 @@ per \var{sigev\_notify}, \signal{SIGALRM} per \var{sigev\_signo} e l'identificatore del timer come valore per \var{sigev\_value.sival\_int}. Il terzo argomento deve essere l'indirizzo di una variabile di tipo -\type{timer\_t} dove sarà scritto l'identificativo associato al timer appena +\typed{timer\_t} dove sarà scritto l'identificativo associato al timer appena creato, da usare in tutte le successive funzioni di gestione. Una volta creato questo identificativo resterà univoco all'interno del processo stesso fintanto che il timer non viene cancellato. @@ -3813,7 +3809,7 @@ prototipi sono: Le due funzioni prendono come primo argomento la variabile su cui viene salvato il contesto dello \textit{stack} per permettere il salto non-locale; -nel caso specifico essa è di tipo \type{sigjmp\_buf}, e non \type{jmp\_buf} +nel caso specifico essa è di tipo \typed{sigjmp\_buf}, e non \type{jmp\_buf} come per le analoghe di sez.~\ref{sec:proc_longjmp} in quanto in questo caso viene salvata anche la maschera dei segnali.