agiunti TODO, informazioni e riferimenti

[gapil.git] / signal.tex

diff --git a/signal.tex b/signal.tex
index 936397deaa1b2b295d5b7bc05546be4c44a93dc2..08f7b8d2d504695f5b9fb5ddcdd0d2f626367c68 100644 (file)
--- 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}.
 
 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
 
 \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
 
 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
 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
 
 \begin{figure}[!htb]
   \footnotesize \centering


@@ -2066,13 +2059,19 @@ più usato.
   \label{fig:sig_sigaction}
 \end{figure}
 
   \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
 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
 
 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.\\ 
                             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
     \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}
 
   \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
 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}.
 
   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
 \begin{table}[!htb]
   \footnotesize
   \centering


@@ -2223,6 +2225,15 @@ altre informazioni specifiche.
   \label{tab:sig_si_code_generic}
 \end{table}
 
   \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
 
 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.
 
 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 è:
 


@@ -3838,16 +3846,21 @@ tipo \type{sigjmp\_buf}, è assolutamente identica a \func{longjmp}.
 \label{sec:sig_pid_fd}
 
 
 \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/,
 % 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
 
 
 % LocalWords:  kernel POSIX timer shell control ctrl kill raise signal handler