X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=8af17a65129cf0e5ddab2fa4cf41b6580f5fccd9;hp=3c794a665bf623627a684907ad99f856a2d2551b;hb=a377dc5a0a0638f0847f27b66f0b095609777320;hpb=51ac65a077651bde52ce68d43aa61b158f5dbd3d

diff --git a/signal.tex b/signal.tex
index 3c794a6..8af17a6 100644
--- a/signal.tex
+++ b/signal.tex
@@ -1,6 +1,6 @@
 %% 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",
@@ -322,9 +322,9 @@ Linux anche a seconda della architettura hardware e della versione del kernel.
 
 Quelli che invece sono stati, almeno a grandi linee, standardizzati, sono i
 nomi dei segnali e le costanti di preprocessore che li identificano, che sono
-tutte nella forma \texttt{SIGnome}, e sono queste che devono essere usate nei
-programmi. Come tutti gli altri nomi e le funzioni che concernono i segnali,
-esse sono definite nell'header di sistema \headfile{signal.h}.
+tutte nella forma \texttt{SIG\textsl{NOME}}, e sono queste che devono essere
+usate nei programmi. Come tutti gli altri nomi e le funzioni che concernono i
+segnali, esse sono definite nell'header di sistema \headfile{signal.h}.
 
 \begin{table}[!htb]
   \footnotesize
@@ -700,7 +700,7 @@ in cui si trattano gli argomenti relativi.  Questi segnali sono:
   La maggior pare dei programmi non hanno necessità di intercettare il
   segnale, in quanto esso è completamente trasparente rispetto all'esecuzione
   che riparte senza che il programma noti niente. Si possono installare dei
-  gestori per far si che un programma produca una qualche azione speciale
+  gestori per far sì che un programma produca una qualche azione speciale
   se viene fermato e riavviato, come per esempio riscrivere un prompt, o
   inviare un avviso. 
 
@@ -944,16 +944,16 @@ situazione è il seguente:
   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})
-\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
@@ -964,7 +964,7 @@ gestori controllino lo stato di uscita delle funzioni che eseguono una system
 call lenta per ripeterne la chiamata qualora l'errore fosse questo.
 
 Dimenticarsi di richiamare una \textit{system call} interrotta da un segnale è
-un errore comune, tanto che le \acr{glibc} provvedono una macro
+un errore comune, tanto che la \acr{glibc} provvede una macro
 \code{TEMP\_FAILURE\_RETRY(expr)} che esegue l'operazione automaticamente,
 ripetendo l'esecuzione dell'espressione \var{expr} fintanto che il risultato
 non è diverso dall'uscita con un errore \errcode{EINTR}.
@@ -976,7 +976,7 @@ bisogno di preoccuparsi di controllare il codice di errore; si perde però la
 possibilità di eseguire azioni specifiche all'occorrenza di questa particolare
 condizione.
 
-Linux e le \acr{glibc} consentono di utilizzare entrambi gli approcci,
+Linux e la \acr{glibc} consentono di utilizzare entrambi gli approcci,
 attraverso una opportuna opzione di \func{sigaction} (vedi
 sez.~\ref{sec:sig_sigaction}). È da chiarire comunque che nel caso di
 interruzione nel mezzo di un trasferimento parziale di dati, le \textit{system
@@ -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*}
-\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}).
-\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 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},
@@ -1043,7 +1043,7 @@ comportamento, pur mantenendone immutato il prototipo\footnote{in realtà in
 
 In questa definizione per l'argomento \param{handler} che indica il gestore da
 installare si è usato un tipo di dato, \type{sighandler\_t}, che è una
-estensione GNU, definita dalle \acr{glibc}, che permette di riscrivere il
+estensione GNU, definita dalla \acr{glibc}, che permette di riscrivere il
 prototipo di \func{signal} nella forma appena vista, molto più leggibile di
 quanto non sia la versione originaria, che di norma è definita come:
 \includecodesnip{listati/signal.c}
@@ -1092,7 +1092,7 @@ librerie del C come la \acr{libc4} e la \acr{libc5}.\footnote{nelle
   ridefinita per seguire la semantica affidabile usata da BSD.}
 
 Al contrario BSD segue la semantica affidabile, non disinstallando il gestore
-e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo delle
+e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo della
 \acr{glibc} dalla versione 2 anche Linux è passato a questo comportamento.  Il
 comportamento della versione originale della funzione, il cui uso è deprecato
 per i motivi visti in sez.~\ref{sec:sig_semantics}, può essere ottenuto
@@ -1419,7 +1419,7 @@ questo modo il ciclo verrà ripetuto; se invece il valore di \var{it\_interval}
 L'uso di \func{setitimer} consente dunque un controllo completo di tutte le
 caratteristiche dei timer, ed in effetti la stessa \func{alarm}, benché
 definita direttamente nello standard POSIX.1, può a sua volta essere espressa
-in termini di \func{setitimer}, come evidenziato dal manuale delle \acr{glibc}
+in termini di \func{setitimer}, come evidenziato dal manuale della \acr{glibc}
 \cite{GlibcMan} che ne riporta la definizione mostrata in
 fig.~\ref{fig:sig_alarm_def}.\footnote{questo comporta anche che non è il caso
   di mescolare chiamate ad \func{abort} e a \func{setitimer}.}
@@ -1565,15 +1565,15 @@ realizzata con l'uso di \func{pause} e \func{alarm}, in una maniera analoga a
 quella dell'esempio che vedremo in sez.~\ref{sec:sig_example}. In tal caso
 mescolare chiamate di \func{alarm} e \func{sleep} o modificare l'azione
 associata \signal{SIGALRM}, può portare a dei risultati indefiniti. Nel caso
-delle \acr{glibc} è stata usata una implementazione completamente indipendente
+della \acr{glibc} è stata usata una implementazione completamente indipendente
 e questi problemi non ci sono, ma un programma portabile non può fare questa
 assunzione.
 
 La granularità di \func{sleep} permette di specificare attese soltanto in
 secondi, per questo sia sotto BSD4.3 che in SUSv2 è stata definita un'altra
 funzione con una precisione teorica del microsecondo. I due standard hanno
-delle definizioni diverse, ma le \acr{glibc} seguono (secondo la pagina di
-manuale almeno dalla versione 2.2.2) seguono quella di SUSv2 per cui la
+delle definizioni diverse, ma la \acr{glibc} segue (secondo la pagina di
+manuale almeno dalla versione 2.2.2)  quella di SUSv2 per cui la
 funzione \funcd{usleep} (dove la \texttt{u} è intesa come sostituzione di
 $\mu$), ha il seguente prototipo:
 
@@ -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.
 
-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}
@@ -2707,8 +2707,8 @@ massimo associato ad un segnale \textit{real-time}.
 Su Linux di solito il primo valore è 33, mentre il secondo è \code{\_NSIG-1},
 che di norma (vale a dire sulla piattaforma i386) è 64. Questo dà un totale di
 32 segnali disponibili, contro gli almeno 8 richiesti da POSIX.1b. Si tenga
-presente però che i primi segnali \textit{real-time} disponibili vendono usati
-dalle \acr{glibc} per l'implementazione dei \textit{thread} POSIX (vedi
+presente però che i primi segnali \textit{real-time} disponibili vengono usati
+dalla \acr{glibc} per l'implementazione dei \textit{thread} POSIX (vedi
 sez.~\ref{sec:thread_posix_intro}), ed il valore di \const{SIGRTMIN} viene
 modificato di conseguenza.\footnote{per la precisione vengono usati i primi
   tre per la vecchia implementazione dei \textit{LinuxThread} ed i primi due
@@ -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.
 
-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{\_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
@@ -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.
 
-\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
@@ -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.
 
-\itindend{thread} 
-
 
 \subsection{La gestione avanzata delle temporizzazioni}
 \label{sec:sig_timer_adv}
@@ -3047,11 +3043,17 @@ tab.~\ref{tab:sig_timer_clockid_types}.
 \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 
 
-Per poter utilizzare queste funzionalità le \acr{glibc} richiedono che la
+Per poter utilizzare queste funzionalità la \acr{glibc} richiede che la
 macro \macro{\_POSIX\_C\_SOURCE} sia definita ad un valore maggiore o uguale
 di \texttt{199309L} (vedi sez.~\ref{sec:intro_gcc_glibc_std}), inoltre i
 programmi che le usano devono essere collegati con la libreria delle
@@ -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
-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 è:
 
@@ -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.
 
-\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
@@ -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.
 
-\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
@@ -3785,7 +3783,7 @@ 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
+\func{longjmp}, ed il comportamento della \acr{glibc} dipende da quale delle
 caratteristiche si sono abilitate con le macro viste in
 sez.~\ref{sec:intro_gcc_glibc_std}.