Ancora revisione

[gapil.git] / signal.tex

diff --git a/signal.tex b/signal.tex
index 3c794a665bf623627a684907ad99f856a2d2551b..8b2521959e1cf1edc08ca15be5359074638da2e8 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -1,6 +1,6 @@
 %% signal.tex
 %%
 %% signal.tex
 %%

-%% Copyright (C) 2000-2015 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2018 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",
 %% 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",


@@ -944,16 +944,16 @@ situazione è il seguente:
   essere riavvolto);
 \item le operazioni eseguite con \func{ioctl} che non è detto possano essere
   eseguite immediatamente;
   essere riavvolto);
 \item le operazioni eseguite con \func{ioctl} che non è detto possano essere
   eseguite immediatamente;

-\item le funzioni di intercomunicazione fra processi (vedi cap.~\ref{cha:IPC})
-  che si bloccano in attesa di risposte da altri processi;
-\item la funzione \func{pause} (vedi sez.~\ref{sec:sig_pause_sleep}) e le
-  analoghe \func{sigsuspend}, \func{sigtimedwait}, e \func{sigwaitinfo} (vedi
-  sez.~\ref{sec:sig_real_time}), usate appunto per attendere l'arrivo di un
-  segnale;
-\item le funzioni associate al \textit{file locking} (vedi
+\item l'uso di funzioni di intercomunicazione fra processi (vedi
+  cap.~\ref{cha:IPC}) che si bloccano in attesa di risposte da altri processi;
+\item l'uso della funzione \func{pause} (vedi sez.~\ref{sec:sig_pause_sleep})
+  e le analoghe \func{sigsuspend}, \func{sigtimedwait}, e \func{sigwaitinfo}
+  (vedi sez.~\ref{sec:sig_real_time}), usate appunto per attendere l'arrivo di
+  un segnale;
+\item l'uso delle funzioni associate al \textit{file locking} (vedi

   sez.~\ref{sec:file_locking})
   sez.~\ref{sec:file_locking})

-\item la funzione \func{wait} e le analoghe funzioni di attesa se nessun
-  processo figlio è ancora terminato.
+\item l'uso della funzione \func{wait} e le analoghe funzioni di attesa se
+  nessun processo figlio è ancora terminato.

 \end{itemize*}
 
 In questo caso si pone il problema di cosa fare una volta che il gestore sia
 \end{itemize*}
 
 In questo caso si pone il problema di cosa fare una volta che il gestore sia


@@ -987,18 +987,18 @@ interrotte con un errore di \errcode{EINTR} indipendentemente dal fatto che ne
 possa essere stato richiesto il riavvio automatico, queste funzioni sono:
 
 \begin{itemize*}
 possa essere stato richiesto il riavvio automatico, queste funzioni sono:
 
 \begin{itemize*}

-\item le funzioni di attesa di un segnale, come \func{pause} (vedi
-  sez.~\ref{sec:sig_pause_sleep}), \func{sigsuspend}, \func{sigtimedwait}, e
+\item le funzioni di attesa di un segnale: \func{pause} (vedi
+  sez.~\ref{sec:sig_pause_sleep}) o \func{sigsuspend}, \func{sigtimedwait}, e

   \func{sigwaitinfo} (vedi sez.~\ref{sec:sig_real_time}).
   \func{sigwaitinfo} (vedi sez.~\ref{sec:sig_real_time}).

-\item le funzioni di attesa dell'\textit{I/O multiplexing}, come
-  \func{select}, \func{pselect}, \func{poll}, \func{ppoll}, \func{epoll\_wait}
-  e \func{epoll\_pwait} (vedi sez.~\ref{sec:file_multiplexing}).
+\item le funzioni di attesa dell'\textit{I/O multiplexing} (vedi
+  sez.~\ref{sec:file_multiplexing}) come \func{select}, \func{pselect},
+  \func{poll}, \func{ppoll}, \func{epoll\_wait} e \func{epoll\_pwait}.

 \item le funzioni del System V IPC che prevedono attese: \func{msgrcv},
   \func{msgsnd} (vedi sez.~\ref{sec:ipc_sysv_mq}), \func{semop} e
   \func{semtimedop} (vedi sez.~\ref{sec:ipc_sysv_sem}).
 \item le funzioni del System V IPC che prevedono attese: \func{msgrcv},
   \func{msgsnd} (vedi sez.~\ref{sec:ipc_sysv_mq}), \func{semop} e
   \func{semtimedop} (vedi sez.~\ref{sec:ipc_sysv_sem}).

-\item le funzioni di attesa di un processo: \func{usleep}, \func{nanosleep}
-  (vedi sez.~\ref{sec:sig_pause_sleep}) e \func{clock\_nanosleep} (vedi
-  sez.~\ref{sec:sig_timer_adv}).
+\item le funzioni per la messa in attesa di un processo come \func{usleep},
+  \func{nanosleep} (vedi sez.~\ref{sec:sig_pause_sleep}) e
+  \func{clock\_nanosleep} (vedi sez.~\ref{sec:sig_timer_adv}).

 \item le funzioni che operano sui socket quando è stato impostato un
   \textit{timeout} sugli stessi con \func{setsockopt} (vedi
   sez.~\ref{sec:sock_generic_options}) ed in particolare \func{accept},
 \item le funzioni che operano sui socket quando è stato impostato un
   \textit{timeout} sugli stessi con \func{setsockopt} (vedi
   sez.~\ref{sec:sock_generic_options}) ed in particolare \func{accept},


@@ -2001,10 +2001,10 @@ relativi all'uso di \func{signal}. Per ovviare a tutto questo lo standard
 POSIX.1 ha ridefinito completamente l'interfaccia per la gestione dei segnali,
 rendendola molto più flessibile e robusta, anche se leggermente più complessa.
 
 POSIX.1 ha ridefinito completamente l'interfaccia per la gestione dei segnali,
 rendendola molto più flessibile e robusta, anche se leggermente più complessa.
 

-La funzione di sistema principale prevista dall'interfaccia POSIX.1 per i
-segnali è \funcd{sigaction}. Essa ha sostanzialmente lo stesso uso di
-\func{signal}, permette cioè di specificare le modalità con cui un segnale può
-essere gestito da un processo. Il suo prototipo è:
+La principale funzione di sistema prevista dall'interfaccia POSIX.1 per la
+gestione dei segnali è \funcd{sigaction}. Essa ha sostanzialmente lo stesso
+uso di \func{signal}, permette cioè di specificare le modalità con cui un
+segnale può essere gestito da un processo. Il suo prototipo è:

 
 \begin{funcproto}{
 \fhead{signal.h}
 
 \begin{funcproto}{
 \fhead{signal.h}


@@ -2820,11 +2820,11 @@ nell'argomento \param{value}. Se invece si è installato un gestore nella forma
 classica il segnale sarà generato, ma tutte le caratteristiche tipiche dei
 segnali \textit{real-time} (priorità e coda) saranno perse.
 
 classica il segnale sarà generato, ma tutte le caratteristiche tipiche dei
 segnali \textit{real-time} (priorità e coda) saranno perse.
 

-Secondo lo standard POSIX la profondità della coda è indicata dalla costante
+Per lo standard POSIX la profondità della coda è indicata dalla costante

 \constd{SIGQUEUE\_MAX}, una della tante costanti di sistema definite dallo
 standard POSIX che non abbiamo riportato esplicitamente in
 sez.~\ref{sec:sys_limits}. Il suo valore minimo secondo lo standard,
 \constd{SIGQUEUE\_MAX}, una della tante costanti di sistema definite dallo
 standard POSIX che non abbiamo riportato esplicitamente in
 sez.~\ref{sec:sys_limits}. Il suo valore minimo secondo lo standard,

-\constd{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux la coda ha una
+\macrod{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux la coda ha una

 dimensione variabile; fino alla versione 2.6.7 c'era un limite massimo globale
 che poteva essere impostato come parametro del kernel in
 \sysctlfiled{kernel/rtsig-max} ed il valore predefinito era pari a 1024. A
 dimensione variabile; fino alla versione 2.6.7 c'era un limite massimo globale
 che poteva essere impostato come parametro del kernel in
 \sysctlfiled{kernel/rtsig-max} ed il valore predefinito era pari a 1024. A


@@ -2911,8 +2911,6 @@ ci sono segnali pendenti la funzione ritornerà immediatamente, in questo modo
 si può eliminare un segnale dalla coda senza dover essere bloccati qualora
 esso non sia presente.
 
 si può eliminare un segnale dalla coda senza dover essere bloccati qualora
 esso non sia presente.
 

-\itindbeg{thread} 
-

 L'uso di queste funzioni è principalmente associato alla gestione dei segnali
 con i \textit{thread}. In genere esse vengono chiamate dal \textit{thread}
 incaricato della gestione, che al ritorno della funzione esegue il codice che
 L'uso di queste funzioni è principalmente associato alla gestione dei segnali
 con i \textit{thread}. In genere esse vengono chiamate dal \textit{thread}
 incaricato della gestione, che al ritorno della funzione esegue il codice che


@@ -2924,8 +2922,6 @@ che venga eseguita l'azione predefinita, devono essere mascherati per tutti i
 \textit{thread}, compreso quello dedicato alla gestione, che potrebbe
 riceverlo fra due chiamate successive.
 
 \textit{thread}, compreso quello dedicato alla gestione, che potrebbe
 riceverlo fra due chiamate successive.
 

-\itindend{thread} 
-

 
 \subsection{La gestione avanzata delle temporizzazioni}
 \label{sec:sig_timer_adv}
 
 \subsection{La gestione avanzata delle temporizzazioni}
 \label{sec:sig_timer_adv}


@@ -3047,6 +3043,12 @@ tab.~\ref{tab:sig_timer_clockid_types}.
 \end{table}
 
 
 \end{table}
 
 

+% TODO: dal 4.17 CLOCK_MONOTONIC e CLOCK_BOOTTIME sono identici vedi
+% https://lwn.net/Articles/751651/ e
+% https://git.kernel.org/linus/d6ed449afdb38f89a7b38ec50e367559e1b8f71f
+% change reverted, vedi: https://lwn.net/Articles/752757/
+
+

 % 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 
 % 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 


@@ -3559,7 +3561,7 @@ singolo (in gergo \textit{one shot}).
 
 Infine, quando un timer non viene più utilizzato, lo si può cancellare,
 rimuovendolo dal sistema e recuperando le relative risorse, effettuando in
 
 Infine, quando un timer non viene più utilizzato, lo si può cancellare,
 rimuovendolo dal sistema e recuperando le relative risorse, effettuando in

-sostanza l'operazione inversa rispetto a \funcd{timer\_create}. Per questo
+sostanza l'operazione inversa rispetto a \func{timer\_create}. Per questo

 compito lo standard prevede una apposita funzione di sistema,
 \funcd{timer\_delete}, il cui prototipo è:
 
 compito lo standard prevede una apposita funzione di sistema,
 \funcd{timer\_delete}, il cui prototipo è:
 


@@ -3668,8 +3670,6 @@ dato che essa può solo assicurare che un segnale è stato inviato, dato che
 escluderne l'avvenuto invio al momento della chiamata non significa nulla
 rispetto a quanto potrebbe essere in un qualunque momento successivo.
 
 escluderne l'avvenuto invio al momento della chiamata non significa nulla
 rispetto a quanto potrebbe essere in un qualunque momento successivo.
 

-\itindbeg{stack} 
-

 Una delle caratteristiche di BSD, disponibile anche in Linux, è la possibilità
 di usare uno \textit{stack} alternativo per i segnali; è cioè possibile fare
 usare al sistema un altro \textit{stack} (invece di quello relativo al
 Una delle caratteristiche di BSD, disponibile anche in Linux, è la possibilità
 di usare uno \textit{stack} alternativo per i segnali; è cioè possibile fare
 usare al sistema un altro \textit{stack} (invece di quello relativo al


@@ -3770,8 +3770,6 @@ si accresce automaticamente (ed infatti eccederne le dimensioni può portare a
 conseguenze imprevedibili).  Si ricordi infine che una chiamata ad una
 funzione della famiglia \func{exec} cancella ogni \textit{stack} alternativo.
 
 conseguenze imprevedibili).  Si ricordi infine che una chiamata ad una
 funzione della famiglia \func{exec} cancella ogni \textit{stack} alternativo.
 

-\itindend{stack} 
-

 Abbiamo visto in fig.~\ref{fig:sig_sleep_incomplete} come si possa usare
 \func{longjmp} per uscire da un gestore rientrando direttamente nel corpo
 del programma, sappiamo però che nell'esecuzione di un gestore il segnale
 Abbiamo visto in fig.~\ref{fig:sig_sleep_incomplete} come si possa usare
 \func{longjmp} per uscire da un gestore rientrando direttamente nel corpo
 del programma, sappiamo però che nell'esecuzione di un gestore il segnale