%% signal.tex
%%
-%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2015 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
\textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
per tutto il tempo che passa fra la generazione del segnale e la sua consegna
esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
-procedura viene effettuata dallo \itindex{scheduler} scheduler quando,
-riprendendo l'esecuzione del processo in questione, verifica la presenza del
-segnale nella \struct{task\_struct} e mette in esecuzione il gestore.
+procedura viene effettuata dallo \textit{scheduler} quando, riprendendo
+l'esecuzione del processo in questione, verifica la presenza del segnale nella
+\struct{task\_struct} e mette in esecuzione il gestore.
In questa semantica un processo ha la possibilità di bloccare la consegna dei
segnali, in questo caso, se l'azione per il suddetto segnale non è quella di
ignorarlo.
Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
-avviene non appena questo viene rimesso in esecuzione dallo
-\itindex{scheduler} scheduler che esegue l'azione specificata. Questo a meno
-che il segnale in questione non sia stato bloccato prima della notifica, nel
-qual caso l'invio non avviene ed il segnale resta \textsl{pendente}
-indefinitamente.
+avviene non appena questo viene rimesso in esecuzione dallo \textit{scheduler}
+che esegue l'azione specificata. Questo a meno che il segnale in questione non
+sia stato bloccato prima della notifica, nel qual caso l'invio non avviene ed
+il segnale resta \textsl{pendente} indefinitamente.
Quando lo si sblocca un segnale \textsl{pendente} sarà subito notificato. Si
tenga presente però che tradizionalmente i segnali \textsl{pendenti} non si
arrotondato al multiplo successivo di 1/\const{HZ}.
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.
+precise del centesimo di secondo usando politiche di \textit{scheduling}
+\textit{real-time} come \const{SCHED\_FIFO} o \const{SCHED\_RR} (vedi
+sez.~\ref{sec:proc_real_time}); 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}
Dato che è nostra intenzione utilizzare \signal{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
+il precedente (\texttt{\small 14--17}). Si effettuerà poi una chiamata ad
\func{alarm} per specificare il tempo d'attesa per l'invio del segnale a cui
segue la chiamata a \func{pause} per fermare il programma (\texttt{\small
- 18-20}) fino alla sua ricezione. Al ritorno di \func{pause}, causato dal
-ritorno del gestore (\texttt{\small 1-9}), si ripristina il gestore originario
-(\texttt{\small 21-22}) restituendo l'eventuale tempo rimanente
-(\texttt{\small 23-24}) che potrà essere diverso da zero qualora
+ 18--20}) fino alla sua ricezione. Al ritorno di \func{pause}, causato dal
+ritorno del gestore (\texttt{\small 1--9}), si ripristina il gestore originario
+(\texttt{\small 21--22}) restituendo l'eventuale tempo rimanente
+(\texttt{\small 23--24}) che potrà essere diverso da zero qualora
l'interruzione di \func{pause} venisse causata da un altro segnale.
Questo codice però, a parte il non gestire il caso in cui si è avuta una
\label{fig:sig_sleep_incomplete}
\end{figure}
-In questo caso il gestore (\texttt{\small 18-27}) non ritorna come in
+In questo caso il gestore (\texttt{\small 18--27}) non ritorna come in
fig.~\ref{fig:sig_sleep_wrong}, ma usa la funzione \func{longjmp}
(\texttt{\small 25}) per rientrare direttamente nel corpo principale del
programma. Dato che in questo caso il valore di uscita che verrà restituito da
-\func{setjmp} è 1, grazie alla condizione impostata in (\texttt{\small 9-12})
+\func{setjmp} è 1, grazie alla condizione impostata in (\texttt{\small 9--12})
si potrà evitare comunque che \func{pause} sia chiamata a vuoto.
Ma anche questa implementazione comporta dei problemi, in questo caso infatti
quello riportato in fig.~\ref{fig:sig_event_wrong}.
La logica del programma è quella di far impostare al gestore (\texttt{\small
- 14-19}) una \index{variabili!globali} variabile globale, preventivamente
+ 14--19}) una \index{variabili!globali} variabile globale, preventivamente
inizializzata nel programma principale, ad un diverso valore. In questo modo
dal corpo principale del programma si potrà determinare, osservandone il
contenuto di detta variabile, l'occorrenza o meno del segnale, ed eseguire le
-azioni conseguenti (\texttt{\small 6-11}) relative.
+azioni conseguenti (\texttt{\small 6--11}) relative.
\begin{figure}[!htbp]
\footnotesize\centering
\const{SI\_SIGIO} & Segnale di \signal{SIGIO} da una coda (vedi
sez.~\ref{sec:file_asyncronous_operation}).\\
\const{SI\_TKILL} & Inviato da \func{tkill} o \func{tgkill} (vedi
- sez.~\ref{cha:threads_xxx}), introdotto con il kernel
+ sez.~\ref{cha:thread_xxx}), introdotto con il kernel
2.4.19.\\
\hline
\end{tabular}
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})
-non esegue nessuna operazione, limitandosi a ritornare per interrompere il
-programma messo in attesa.
+l'uso di \func{longjmp}. Come in precedenza il gestore (\texttt{\small
+ 27--30}) non esegue nessuna operazione, limitandosi a ritornare per
+interrompere il programma messo in attesa.
-La prima parte della funzione (\texttt{\small 6-10}) provvede ad installare
+La prima parte della funzione (\texttt{\small 6--10}) provvede ad installare
l'opportuno gestore per \signal{SIGALRM}, salvando quello originario, che
sarà ripristinato alla conclusione della stessa (\texttt{\small 23}); il passo
-successivo è quello di bloccare \signal{SIGALRM} (\texttt{\small 11-14}) per
+successivo è quello di bloccare \signal{SIGALRM} (\texttt{\small 11--14}) per
evitare che esso possa essere ricevuto dal processo fra l'esecuzione di
\func{alarm} (\texttt{\small 16}) e la sospensione dello stesso. Nel fare
questo si salva la maschera corrente dei segnali, che sarà ripristinata alla
versione 2.1 della \acr{glibc}.} in particolare sono stati superati tre
limiti fondamentali dei segnali classici:
\begin{basedescript}{\desclabelwidth{1cm}\desclabelstyle{\nextlinelabel}}
-\item[I segnali non sono accumulati]
+\item[\textbf{I segnali non sono accumulati}]
se più segnali vengono generati prima dell'esecuzione di un gestore
questo sarà eseguito una sola volta, ed il processo non sarà in grado di
accorgersi di quante volte l'evento che ha generato il segnale è accaduto.
-\item[I segnali non trasportano informazione]
+\item[\textbf{I segnali non trasportano informazione}]
i segnali classici non prevedono altra informazione sull'evento
che li ha generati se non il fatto che sono stati emessi (tutta
l'informazione che il kernel associa ad un segnale è il suo numero).
-\item[I segnali non hanno un ordine di consegna]
+\item[\textbf{I segnali non hanno un ordine di consegna}]
l'ordine in cui diversi segnali vengono consegnati è casuale e non
prevedibile. Non è possibile stabilire una priorità per cui la reazione a
certi segnali ha la precedenza rispetto ad altri.
\end{table}
-% NOTE: dal 2.6.39 anche CLOCK_BOOTTIME_ALARM e CLOCK_BOOTTIME
% NOTE: dal 3.0 anche i cosiddetti Posix Alarm Timers, con
% CLOCK_REALTIME_ALARM vedi http://lwn.net/Articles/429925/
+% TODO: dal 3.10 anche CLOCK_TAI
Per poter utilizzare queste funzionalità le \acr{glibc} richiedono che la
macro \macro{\_POSIX\_C\_SOURCE} sia definita ad un valore maggiore o uguale
projects / gapil.git / blobdiff