X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=08f7b8d2d504695f5b9fb5ddcdd0d2f626367c68;hp=936397deaa1b2b295d5b7bc05546be4c44a93dc2;hb=fddf66ed6c48647cbab38b3a27c4a12feb74b86c;hpb=4a4c9aa963c52279a1c3aa5c7c4b31aca927f3f5

diff --git a/signal.tex b/signal.tex
index 936397d..08f7b8d 100644
--- a/signal.tex
+++ b/signal.tex
@@ -1837,12 +1837,12 @@ che si fa in questo caso è impostare all'interno del gestore un opportuno flag
 da controllare nel corpo principale del programma, con un codice del tipo di
 quello riportato in fig.~\ref{fig:sig_event_wrong}.
 
-La logica del programma è quella di far impostare al gestore (\texttt{\small
-  14--19}) una 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.
+La logica del programma è quella di impostare nel gestore una variabile
+globale preventivamente inizializzata nel programma principale ad un valore
+diverso (\texttt{\small 14--19}). In questo modo dal corpo principale del
+programma si potrà determinare, osservando il contenuto di detta variabile,
+l'occorrenza o meno del segnale, ed eseguire le conseguenti azioni relative
+(\texttt{\small 6--11}).
 
 \begin{figure}[!htbp]
   \footnotesize\centering
@@ -1865,11 +1865,11 @@ la sua occorrenza sarà perduta.
 
 Questi esempi ci mostrano come per poter eseguire una gestione effettiva dei
 segnali occorrono delle funzioni più sofisticate di quelle finora
-illustrate. La funzione \func{signal} infatti ha la sua origine nella
-interfaccia alquanto primitiva che venne adottata nei primi sistemi Unix, ma
-con questa funzione è sostanzialmente impossibile gestire in maniera adeguata
-di tutti i possibili aspetti con cui un processo deve reagire alla ricezione
-di un segnale.
+illustrate. La funzione \func{signal} infatti ha la sua origine
+nell'interfaccia alquanto primitiva che venne adottata nei primi sistemi Unix,
+ma con questa funzione è sostanzialmente impossibile gestire in maniera
+adeguata di tutti i possibili aspetti con cui un processo deve reagire alla
+ricezione di un segnale.
 
 
 
@@ -2045,16 +2045,9 @@ da esso specificata, se \param{oldact} non è nullo il valore dell'azione
 corrente viene restituito indietro.  Questo permette (specificando \param{act}
 nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
 che non consente di ottenere l'azione corrente senza installarne una nuova. Se
-sia \param{act} che \param{oldact} la funzione può essere utilizzata per
-verificare, se da luogo ad un errore, se il segnale indicato è valido per la
-piattaforma che si sta usando.
-
-Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
-tramite la quale si specificano tutte le caratteristiche dell'azione associata
-ad un segnale.  Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
-definita secondo quanto riportato in fig.~\ref{fig:sig_sigaction}. Il campo
-\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
-più usato.
+sia \param{act} che \param{oldact} sono nulli la funzione può essere
+utilizzata per verificare che il segnale indicato sia valido per la
+piattaforma che si sta usando (se non lo è darà errore).
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -2066,13 +2059,19 @@ più usato.
   \label{fig:sig_sigaction}
 \end{figure}
 
+Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
+tramite la quale si specificano tutte le caratteristiche dell'azione associata
+ad un segnale.  Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
+definita secondo quanto riportato in fig.~\ref{fig:sig_sigaction}. Il campo
+\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
+più usato.
+
 Il campo \var{sa\_mask} serve ad indicare l'insieme dei segnali che devono
 essere bloccati durante l'esecuzione del gestore, ad essi viene comunque
 sempre aggiunto il segnale che ne ha causato la chiamata, a meno che non si
-sia specificato con \var{sa\_flag} un comportamento diverso. Quando il
-gestore ritorna comunque la maschera dei segnali bloccati (vedi
-sez.~\ref{sec:sig_sigmask}) viene ripristinata al valore precedente
-l'invocazione.
+sia specificato con \var{sa\_flag} un comportamento diverso. Quando il gestore
+ritorna la maschera dei segnali bloccati (vedi sez.~\ref{sec:sig_sigmask})
+viene comunque ripristinata al valore precedente l'invocazione.
 
 L'uso di questo campo permette ad esempio di risolvere il problema residuo
 dell'implementazione di \code{sleep} mostrata in
@@ -2127,6 +2126,11 @@ tab.~\ref{tab:sig_sa_flag}.
                             call} quando vengono interrotte dal suddetto
                             segnale, riproduce cioè il comportamento standard
                             di BSD.\\ 
+    \constd{SA\_RESTORER} & Ad uso delle implementazioni delle liberie del C,
+                            non deve essere usato nelle applicazioni, serve ad
+                            indicare che il campo \var{sa\_restorer} contiene
+                            l'indirizzo di un cosiddetto \textit{signal
+                            trampoline}.\footnotemark \\ 
     \constd{SA\_SIGINFO}  & Deve essere specificato quando si vuole usare un
                             gestore in forma estesa usando
                             \var{sa\_sigaction} al posto di
@@ -2137,6 +2141,13 @@ tab.~\ref{tab:sig_sa_flag}.
   \label{tab:sig_sa_flag}
 \end{table}
 
+\footnotetext{il \itindex{signal~trampoline} \textit{signal trampoline} è il
+  codice usato per tornare da un gestore di segnali, che originariamente
+  veniva inserito nello \textit{stack}, ma i kernel recenti come misura di
+  sicurezza impediscono l'esecuzione di codice dallo stack, per cui questo
+  codice viene spostato altrove (ad esempio nella libreria del C) ed il suo
+  indirizzo viene indicato al kernel nel campo \var{sa\_restorer}.}
+
 Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette
 di utilizzare due forme diverse di gestore,\footnote{la possibilità è prevista
   dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x
@@ -2182,15 +2193,6 @@ viene sempre espresso come una costante,\footnote{le definizioni di tutti i
   valori possibili si trovano in \file{bits/siginfo.h}.} ed i valori possibili
 in questo caso sono riportati in tab.~\ref{tab:sig_si_code_generic}.
 
-Nel caso di alcuni segnali però il valore di \var{si\_code} viene usato per
-fornire una informazione specifica relativa alle motivazioni della ricezione
-dello stesso; ad esempio i vari segnali di errore (\signal{SIGILL},
-\signal{SIGFPE}, \signal{SIGSEGV} e \signal{SIGBUS}) lo usano per fornire
-maggiori dettagli riguardo l'errore, come il tipo di errore aritmetico, di
-istruzione illecita o di violazione di memoria; mentre alcuni segnali di
-controllo (\signal{SIGCHLD}, \signal{SIGTRAP} e \signal{SIGPOLL}) forniscono
-altre informazioni specifiche.
-
 \begin{table}[!htb]
   \footnotesize
   \centering
@@ -2223,6 +2225,15 @@ altre informazioni specifiche.
   \label{tab:sig_si_code_generic}
 \end{table}
 
+Nel caso di alcuni segnali però il valore di \var{si\_code} viene usato per
+fornire una informazione specifica relativa alle motivazioni della ricezione
+dello stesso; ad esempio i vari segnali di errore (\signal{SIGILL},
+\signal{SIGFPE}, \signal{SIGSEGV} e \signal{SIGBUS}) lo usano per fornire
+maggiori dettagli riguardo l'errore, come il tipo di errore aritmetico, di
+istruzione illecita o di violazione di memoria; mentre alcuni segnali di
+controllo (\signal{SIGCHLD}, \signal{SIGTRAP} e \signal{SIGPOLL}) forniscono
+altre informazioni specifiche.
+
 
 In questo caso il valore del campo \var{si\_code} deve essere verificato nei
 confronti delle diverse costanti previste per ciascuno di detti segnali; dato
@@ -3655,9 +3666,6 @@ 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 è:
 
@@ -3838,16 +3846,21 @@ tipo \type{sigjmp\_buf}, è assolutamente identica a \func{longjmp}.
 \label{sec:sig_pid_fd}
 
 
+% TODO: trattare (qui? oppure sopra in "Ulteriori funzioni di gestione?)
+% pidfd_send_signal() introdotta con il kernel 5.1 vedi
+% https://lwn.net/Articles/784831/, https://lwn.net/Articles/773459/ e
+% https://lwn.net/Articles/801319/
+
 % TODO: Nuova subsection sui pidfd, e le funzioni correlate, in particolare:
 % 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
-% trattare pure pidfd_open() (vedi https://lwn.net/Articles/789023/) per
-% ottere un pid fd pollabile aggiunta con il kernel 5.3
-% man pidfd_send_signal su le versioni più recenti della man pages
-
-
+% https://git.kernel.org/linus/3eb39f47934f trattare pure pidfd_open() (vedi
+% https://lwn.net/Articles/789023/) per ottere un pid fd pollabile aggiunta
+% con il kernel 5.3 ed il nuovo flag PIDFD_NONBLOCK aggionto con il 5.10 (vedi
+% https://git.kernel.org/linus/4da9af0014b5), man pidfd_send_signal su le
+% versioni più recenti della man pages trattare pidfd_getfd aggiunta con il
+% kernel 5.6
 
 
 % LocalWords:  kernel POSIX timer shell control ctrl kill raise signal handler