Aggiornamento date copyright più TODO 5.3

[gapil.git] / signal.tex

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

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


@@ -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
 
 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
 
 \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
   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. 
 
   se viene fermato e riavviato, come per esempio riscrivere un prompt, o
   inviare un avviso. 
 


@@ -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 è
 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}.
 \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.
 
 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
 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


@@ -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
 
 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}
 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
   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
 \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


@@ -1287,8 +1287,13 @@ standard POSIX, prima della terminazione tutti i file aperti e gli stream
 saranno chiusi ed i buffer scaricati su disco. Non verranno invece eseguite le
 eventuali funzioni registrate con \func{atexit} e \func{on\_exit}.
 
 saranno chiusi ed i buffer scaricati su disco. Non verranno invece eseguite le
 eventuali funzioni registrate con \func{atexit} e \func{on\_exit}.
 

+% TODO trattare pidfd_send_signal, aggiunta con il kernel 5.1 (vedi
+% https://lwn.net/Articles/783052/) per mandare segnali a processi senza dover
+% usare un PID, vedi anche https://lwn.net/Articles/773459/,
+% https://git.kernel.org/linus/3eb39f47934f 

 
 

-
+% TODO c'è pure pidfd_open() (vedi https://lwn.net/Articles/789023/) per
+% ottere un pid fd pollabile aggiunta con il kernel 5.3

 
 \subsection{Le funzioni di allarme ed i \textit{timer}}
 \label{sec:sig_alarm_abort}
 
 \subsection{Le funzioni di allarme ed i \textit{timer}}
 \label{sec:sig_alarm_abort}


@@ -1333,11 +1338,11 @@ processo tre diversi timer:
   corrisponde al \textit{clock time}). La scadenza di questo timer provoca
   l'emissione di \signal{SIGALRM};
 \item un \textit{virtual timer} che calcola il tempo di processore usato dal
   corrisponde al \textit{clock time}). La scadenza di questo timer provoca
   l'emissione di \signal{SIGALRM};
 \item un \textit{virtual timer} che calcola il tempo di processore usato dal

-  processo in user space (che corrisponde all'\textit{user time}). La scadenza
-  di questo timer provoca l'emissione di \signal{SIGVTALRM};
+  processo in \textit{user space} (che corrisponde all'\textit{user time}). La
+  scadenza di questo timer provoca l'emissione di \signal{SIGVTALRM};

 \item un \textit{profiling timer} che calcola la somma dei tempi di processore
 \item un \textit{profiling timer} che calcola la somma dei tempi di processore

-  utilizzati direttamente dal processo in user space, e dal kernel nelle
-  \textit{system call} ad esso relative (che corrisponde a quello che in
+  utilizzati direttamente dal processo in \textit{user space}, e dal kernel
+  nelle \textit{system call} ad esso relative (che corrisponde a quello che in

   sez.~\ref{sec:sys_unix_time} abbiamo chiamato \textit{processor time}). La
   scadenza di questo timer provoca l'emissione di \signal{SIGPROF}.
 \end{itemize*}
   sez.~\ref{sec:sys_unix_time} abbiamo chiamato \textit{processor time}). La
   scadenza di questo timer provoca l'emissione di \signal{SIGPROF}.
 \end{itemize*}


@@ -1419,7 +1424,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
 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}.}
 \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 +1570,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
 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
 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:
 
 funzione \funcd{usleep} (dove la \texttt{u} è intesa come sostituzione di
 $\mu$), ha il seguente prototipo:
 


@@ -2707,8 +2712,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
 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
 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


@@ -3048,12 +3053,16 @@ tab.~\ref{tab:sig_timer_clockid_types}.
 % https://git.kernel.org/linus/d6ed449afdb38f89a7b38ec50e367559e1b8f71f
 % change reverted, vedi: https://lwn.net/Articles/752757/
 
 % 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 
 

-Per poter utilizzare queste funzionalità le \acr{glibc} richiedono che la
+% TODO seguire l'evoluzione delle nuove syscall per il problema del 2038,
+% iniziate ad entrare nel kernel dal 5.1, vedi
+% https://lwn.net/Articles/776435/, https://lwn.net/Articles/782511/,
+% https://git.kernel.org/linus/b1b988a6a035 
+
+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
 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


@@ -3648,6 +3657,9 @@ In questo ultimo paragrafo esamineremo le rimanenti funzioni di gestione dei
 segnali non descritte finora, relative agli aspetti meno utilizzati e più
 ``\textsl{esoterici}'' della interfaccia.
 
 segnali non descritte finora, relative agli aspetti meno utilizzati e più
 ``\textsl{esoterici}'' della interfaccia.
 

+% TODO: trattare (qui?) pidfd_send_signal() introdotta con il kernel 5.1 vedi
+% https://lwn.net/Articles/784831/ e https://lwn.net/Articles/773459/
+

 La prima di queste funzioni è la funzione di sistema \funcd{sigpending},
 anch'essa introdotta dallo standard POSIX.1, il suo prototipo è:
 
 La prima di queste funzioni è la funzione di sistema \funcd{sigpending},
 anch'essa introdotta dallo standard POSIX.1, il suo prototipo è:
 


@@ -3783,7 +3795,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
 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}.
 
 caratteristiche si sono abilitate con le macro viste in
 sez.~\ref{sec:intro_gcc_glibc_std}.