%% 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
Questo file costituisce il cosiddetto \textit{core dump}, e contenendo
l'immagine della memoria del processo, consente di risalire allo stato dello
-\itindex{stack} \textit{stack} (vedi sez.~\ref{sec:proc_mem_layout}) prima
-della terminazione. Questo permette di esaminare il contenuto del file un
-secondo tempo con un apposito programma (un \textit{debugger} come \cmd{gdb})
-per investigare sulla causa dell'errore, ed in particolare, grazie appunto ai
-dati dello \itindex{stack} \textit{stack}, consente di identificare quale
-funzione ha causato l'errore.
+\textit{stack} (vedi sez.~\ref{sec:proc_mem_layout}) prima della
+terminazione. Questo permette di esaminare il contenuto del file un secondo
+tempo con un apposito programma (un \textit{debugger} come \cmd{gdb}) per
+investigare sulla causa dell'errore, ed in particolare, grazie appunto ai dati
+dello \textit{stack}, consente di identificare quale funzione ha causato
+l'errore.
Si tenga presente che il \textit{core dump} viene creato non solo in caso di
errore effettivo, ma anche se il segnale per cui la sua creazione è prevista
\hline
T & L'azione predefinita è terminare il processo.\\
C & L'azione predefinita è terminare il processo e scrivere un
- \itindex{core~dump} \textit{core dump}.\\
+ \textit{core dump}.\\
I & L'azione predefinita è ignorare il segnale.\\
S & L'azione predefinita è fermare il processo.\\
\hline
L'azione predefinita per tutti questi segnali è causare la terminazione del
processo che li ha causati. In genere oltre a questo il segnale provoca pure
-la registrazione su disco di un file di \itindex{core~dump} \textit{core
- dump}, che un debugger può usare per ricostruire lo stato del programma al
-momento della terminazione. Questi segnali sono:
+la registrazione su disco di un file di \textit{core dump}, che un debugger
+può usare per ricostruire lo stato del programma al momento della
+terminazione. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\signal{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome
derivi da \textit{floating point exception} si applica a tutti gli errori
controllato da un altro carattere di controllo, ``\textit{QUIT}'',
corrispondente alla sequenza \texttt{C-\bslash} sulla tastiera. A differenza
del precedente l'azione predefinita, oltre alla terminazione del processo,
- comporta anche la creazione di un \itindex{core~dump} \textit{core dump}.
- In genere lo si può pensare come corrispondente ad una condizione di errore
- del programma rilevata dall'utente. Per questo motivo non è opportuno fare
- eseguire al gestore di questo segnale le operazioni di pulizia normalmente
- previste (tipo la cancellazione di file temporanei), dato che in certi casi
- esse possono eliminare informazioni utili nell'esame dei \itindex{core~dump}
- \textit{core dump}.
+ comporta anche la creazione di un \textit{core dump}. In genere lo si può
+ pensare come corrispondente ad una condizione di errore del programma
+ rilevata dall'utente. Per questo motivo non è opportuno fare eseguire al
+ gestore di questo segnale le operazioni di pulizia normalmente previste
+ (tipo la cancellazione di file temporanei), dato che in certi casi esse
+ possono eliminare informazioni utili nell'esame dei \textit{core dump}.
\item[\signal{SIGKILL}] Il nome è utilizzato per terminare in maniera immediata
qualunque programma. Questo segnale non può essere né intercettato, né
tempo di CPU disponibile, vedi sez.~\ref{sec:sys_resource_limit}. Fino al
kernel 2.2 terminava semplicemente il processo, a partire dal kernel 2.4,
seguendo le indicazioni dello standard POSIX.1-2001 viene anche generato un
- \itindex{core~dump} \textit{core dump}.
+ \textit{core dump}.
\item[\signal{SIGXFSZ}] Sta per \textit{File size limit exceeded}. Questo
segnale è generato quando un processo tenta di estendere un file oltre le
dimensioni specificate dal limite impostato per le dimensioni massime di un
file, vedi sez.~\ref{sec:sys_resource_limit}. Fino al kernel 2.2 terminava
semplicemente il processo, a partire dal kernel 2.4, seguendo le indicazioni
- dello standard POSIX.1-2001 viene anche generato un \itindex{core~dump}
- \textit{core dump}.
+ dello standard POSIX.1-2001 viene anche generato un \textit{core dump}.
\item[\signal{SIGLOST}] Sta per \textit{Resource lost}. Tradizionalmente è il
segnale che viene generato quando si perde un advisory lock su un file su
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