TODO e novità

[gapil.git] / signal.tex

diff --git a/signal.tex b/signal.tex
index 4a9a5b9e41ead4b30d60fbb0cbfa5668dfc6f9de..0cdf0abc457e53ebdd3d0e8dace2af63e89ef61e 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,9 +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.
+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).

 
 Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
 tramite la quale si specificano tutte le caratteristiche dell'azione associata
 
 Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
 tramite la quale si specificano tutte le caratteristiche dell'azione associata


@@ -3835,10 +3835,10 @@ tipo \type{sigjmp\_buf}, è assolutamente identica a \func{longjmp}.
 \label{sec:sig_pid_fd}
 
 
 \label{sec:sig_pid_fd}
 
 

-% TODO: trattare (qui?) pidfd_send_signal() introdotta con il kernel 5.1 vedi
+% 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/784831/, https://lwn.net/Articles/773459/ e

-% https://lwn.net/Articles/801319/ 
-% oppure sopra in "Ulteriori funzioni di gestione"
+% 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
 
 % TODO: Nuova subsection sui pidfd, e le funzioni correlate, in particolare:
 % trattare pidfd_send_signal, aggiunta con il kernel 5.1 (vedi


@@ -3848,7 +3848,7 @@ tipo \type{sigjmp\_buf}, è assolutamente identica a \func{longjmp}.
 % 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
 % 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

-
+% trattare pidfd_getfd aggiunta con il kernel 5.6