Ancora revisione segnali
[gapil.git] / signal.tex
index 8af17a65129cf0e5ddab2fa4cf41b6580f5fccd9..c408ef30cbfb11306d8cd3b9a73191afaaacb57a 100644 (file)
@@ -1,6 +1,6 @@
 %% 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",
@@ -245,7 +245,6 @@ segnale. Per alcuni segnali (per la precisione \signal{SIGKILL} e
 \signal{SIGSTOP}) questa azione è predeterminata dal kernel e non può essere
 mai modificata, ma per tutti gli altri si può selezionare una delle tre
 possibilità seguenti:
-
 \begin{itemize*}
 \item ignorare il segnale;
 \item intercettare il segnale, ed utilizzare il gestore specificato;
@@ -322,7 +321,7 @@ 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{SIG\textsl{NOME}}, e sono queste che devono essere
+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}.
 
@@ -393,8 +392,7 @@ quelli \textit{real-time} in sez.~\ref{sec:sig_real_time}). Ma si tenga
 presente che solo quelli elencati nella prima sezione della tabella sono
 presenti su tutte le architetture. Nelle sezioni successive si sono riportati
 rispettivamente quelli che esistono solo sull'architettura PC e quelli che non
-esistono sull'architettura PC, ma sono definiti sulle architetture
-\textit{alpha} o \textit{mips}.
+esistono sull'architettura PC, ma sono definiti su altre.
 
 Alcuni segnali erano previsti fin dallo standard ANSI C, ed i segnali sono
 presenti in tutti i sistemi unix-like, ma l'elenco di quelli disponibili non è
@@ -407,7 +405,14 @@ presente che il significato dei segnali è abbastanza indipendente dalle
 implementazioni solo per quelli definiti negli standard POSIX.1-1990 e
 POSIX.1-2001. 
 
-\begin{table}[htb]
+Come accennato in sez.~\ref{sec:sig_notification} a ciascun segnale è
+associata una specifica azione predefinita che viene eseguita quando nessun
+gestore è installato. Le azioni predefinite possibili, che abbiamo già
+descritto in sez.~\ref{sec:sig_notification}, sono state riportate in
+tab.~\ref{tab:sig_signal_list} nella terza colonna, e di nuovo sono state
+indicate con delle lettere la cui legenda completa è illustrata in
+tab.~\ref{tab:sig_action_leg}).
+\begin{table}[!htb]
   \footnotesize
   \centering
   \begin{tabular}[c]{|c|l|}
@@ -428,13 +433,13 @@ POSIX.1-2001.
   \label{tab:sig_standard_leg}
 \end{table}
 
-Come accennato in sez.~\ref{sec:sig_notification} a ciascun segnale è
-associata una specifica azione predefinita che viene eseguita quando nessun
-gestore è installato. Le azioni predefinite possibili, che abbiamo già
-descritto in sez.~\ref{sec:sig_notification}, sono state riportate in
-tab.~\ref{tab:sig_signal_list} nella terza colonna, e di nuovo sono state
-indicate con delle lettere la cui legenda completa è illustrata in
-tab.~\ref{tab:sig_action_leg}).
+Si inoltre noti come \signal{SIGCONT} sia l'unico segnale a non avere
+l'indicazione di una azione predefinita nella terza colonna di
+tab.~\ref{tab:sig_signal_list}, questo perché il suo effetto è sempre quello
+di far ripartire un programma in stato \texttt{T} fermato da un segnale di
+stop. Inoltre i segnali \signal{SIGSTOP} e \signal{SIGKILL} si distinguono da
+tutti gli altri per la specifica caratteristica di non potere essere né
+intercettati, né bloccati, né ignorati.
 
 \begin{table}[htb]
   \footnotesize
@@ -456,15 +461,6 @@ tab.~\ref{tab:sig_action_leg}).
   \label{tab:sig_action_leg}
 \end{table}
 
-
-Si inoltre noti come \signal{SIGCONT} sia l'unico segnale a non avere
-l'indicazione di una azione predefinita nella terza colonna di
-tab.~\ref{tab:sig_signal_list}, questo perché il suo effetto è sempre quello
-di far ripartire un programma in stato \texttt{T} fermato da un segnale di
-stop. Inoltre i segnali \signal{SIGSTOP} e \signal{SIGKILL} si distinguono da
-tutti gli altri per la specifica caratteristica di non potere essere né
-intercettati, né bloccati, né ignorati.
-
 Il numero totale di segnali presenti è dato dalla macro \macrod{NSIG} (e tiene
 conto anche di quelli \textit{real-time}) e dato che i numeri dei segnali sono
 allocati progressivamente, essa corrisponde anche al successivo del valore
@@ -960,8 +956,9 @@ In questo caso si pone il problema di cosa fare una volta che il gestore sia
 ritornato. La scelta originaria dei primi Unix era quella di far ritornare
 anche la \textit{system call} restituendo l'errore di \errcode{EINTR}. Questa
 è a tutt'oggi una scelta corrente, ma comporta che i programmi che usano dei
-gestori controllino lo stato di uscita delle funzioni che eseguono una system
-call lenta per ripeterne la chiamata qualora l'errore fosse questo.
+gestori controllino lo stato di uscita delle funzioni che eseguono una
+\textit{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 la \acr{glibc} provvede una macro
@@ -1053,7 +1050,7 @@ con il precedente prototipo si può dedurre la definizione di
 \typed{sighandler\_t} che è:
 \includecodesnip{listati/sighandler_t.c}
 e cioè un puntatore ad una funzione \ctyp{void} (cioè senza valore di ritorno)
-che prende un argomento di tipo \ctyp{int}. Si noti come si devono usare le
+che prende un argomento di tipo \ctyp{int}. Si noti come si devono usare le
 parentesi intorno al nome della funzione per via delle precedenze degli
 operatori del C, senza di esse si sarebbe definita una funzione che ritorna un
 puntatore a \ctyp{void} e non un puntatore ad una funzione \ctyp{void}.
@@ -1069,10 +1066,12 @@ della funzione da chiamare all'occorrenza del segnale, può assumere anche i
 due valori costanti \const{SIG\_IGN} e \const{SIG\_DFL}. Il primo indica che
 il segnale deve essere ignorato. Il secondo ripristina l'azione predefinita, e
 serve a tornare al comportamento di default quando non si intende più gestire
-direttamente un segnale. Si ricordi però che i due segnali \signal{SIGKILL} e
-\signal{SIGSTOP} non possono essere né ignorati né intercettati e per loro
-l'uso di \func{signal} non ha alcun effetto, qualunque cosa si specifichi
-per \param{handler}.
+direttamente un segnale.
+
+Si ricordi però che i due segnali \signal{SIGKILL} e \signal{SIGSTOP} non
+possono essere né ignorati né intercettati e per loro l'uso di \func{signal}
+non ha alcun effetto, qualunque cosa si specifichi nell'argomento
+\param{handler}.
 
 La funzione restituisce l'indirizzo dell'azione precedente, che può essere
 salvato per poterlo ripristinare (con un'altra chiamata a \func{signal}) in un
@@ -1102,11 +1101,11 @@ chiamando \funcm{sysv\_signal}, una volta che si sia definita la macro
 processo multi-\textit{thread}, è da evitare: tutti i nuovi programmi devono
 usare \func{sigaction}.
 
-È da tenere presente che, seguendo lo standard POSIX, il comportamento di un
-processo che ignora i segnali \signal{SIGFPE}, \signal{SIGILL}, o
-\signal{SIGSEGV}, qualora questi non originino da una chiamata ad una
-\func{kill} o altra funzione affine, è indefinito. Un gestore che ritorna da
-questi segnali può dare luogo ad un ciclo infinito.
+È da tenere presente che su Linux, seguendo lo standard POSIX, il
+comportamento di un processo che ignora i segnali \signal{SIGFPE},
+\signal{SIGILL}, o \signal{SIGSEGV}, qualora questi non originino da una
+chiamata ad una \func{kill} o altra funzione affine, è indefinito. Un gestore
+che ritorna da questi segnali può dare luogo ad un ciclo infinito.
 
 
 \subsection{Le funzioni per l'invio di segnali}
@@ -1147,9 +1146,10 @@ gestore dovrà prima reinstallare l'azione predefinita, per poi attivarla
 chiamando \func{raise}.
 
 In realtà \func{raise} è una funzione di libreria, che per i processi ordinari
-viene implementata attraverso la funzione di sistema \funcd{kill} che è quella
-che consente effettivamente di inviare un segnale generico ad un processo, il
- suo prototipo è:
+veniva implementata (nelle versioni più recenti del kernel viene usata
+\func{tgkill} che vedremo in sez.~\ref{cha:thread_xxx}) attraverso la funzione
+di sistema \funcd{kill} che è quella che consente effettivamente di inviare un
+segnale generico ad un processo, il suo prototipo è:
 
 \begin{funcproto}{
 \fhead{sys/types.h}
@@ -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}.
 
+% 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}
@@ -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
-  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
-  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*}
@@ -3048,11 +3053,15 @@ tab.~\ref{tab:sig_timer_clockid_types}.
 % 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 
 
+% 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
@@ -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.
 
+% 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 è: