Aggiornati elenchi signal safe functions
[gapil.git] / signal.tex
index 2c8661ee99ef18eccad429de0f16e975220184b4..c2446f18d54f8a38c2a9814521bad484af6a2b4c 100644 (file)
@@ -2126,7 +2126,7 @@ 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,
+    \constd{SA\_RESTORER} & Ad uso delle implementazioni delle librerie 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
@@ -2151,7 +2151,7 @@ tab.~\ref{tab:sig_sa_flag}.
 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
-  con l'itroduzione dei segnali \textit{real-time} (vedi
+  con l'introduzione dei segnali \textit{real-time} (vedi
   sez.~\ref{sec:sig_real_time}); in precedenza era possibile ottenere alcune
   informazioni addizionali usando \var{sa\_handler} con un secondo parametro
   addizionale di tipo \var{sigcontext}, che adesso è deprecato.}  da
@@ -2164,7 +2164,7 @@ attraverso la struttura \struct{siginfo\_t}, riportata in
 fig.~\ref{fig:sig_siginfo_t}.  I due campi devono essere usati in maniera
 alternativa, in certe implementazioni questi campi vengono addirittura
 definiti come una \direct{union}.\footnote{la direttiva \direct{union} del
-  linguaggio C definisce una variabile complessa, analoga a una stuttura, i
+  linguaggio C definisce una variabile complessa, analoga a una struttura, i
   cui campi indicano i diversi tipi di valori che possono essere salvati, in
   maniera alternativa, all'interno della stessa.}
 
@@ -2593,29 +2593,22 @@ principale, cosa che ad esempio può rendere problematico chiamare all'interno
 di un gestore di segnali la stessa funzione che dal segnale è stata
 interrotta.
 
+Ad esempio se consideriamo le funzioni dell'I/O standard di
+sez.~\ref{sec:files_std_interface} è chiaro che essendo basate sull'uso da
+parte delle librerie del C di buffer e puntatori interni, che possono essere
+stati aggiornati in maniera parziale alla ricezione di un segnale, questi
+possono trovarsi, quando riutilizzate all'interno di un gestore, in uno stato
+completamente inconsistente.
+
 \index{funzioni!\textit{signal safe}|(}
 
-Il concetto è comunque più generale e porta ad una distinzione fra quelle che
+Il concetto è comunque generale e porta ad una distinzione fra quelle che
 POSIX chiama \textsl{funzioni insicure} (\textit{signal unsafe function}) e
-\textsl{funzioni sicure} (o più precisamente \textit{signal safe function}).
-Quando un segnale interrompe una funzione insicura ed il gestore chiama al suo
-interno una funzione insicura il sistema può dare luogo ad un comportamento
-indefinito, la cosa non avviene invece per le funzioni sicure.
-
-Tutto questo significa che la funzione che si usa come gestore di segnale deve
-essere programmata con molta cura per evirare questa evenienza e che non è
-possibile utilizzare al suo interno una qualunque funzione di sistema, se si
-vogliono evitare questi problemi si può ricorrere soltanto all'uso delle
-funzioni considerate sicure.
-
-L'elenco delle funzioni considerate sicure varia a seconda della
-implementazione utilizzata e dello standard a cui si fa riferimento. Non è
-riportata una lista specifica delle funzioni sicure per Linux, e si suppone
-pertanto che siano quelle richieste dallo standard. Secondo quanto richiesto
-dallo standard POSIX 1003.1 nella revisione del 2003, le ``\textit{signal safe
-  function}'' che possono essere chiamate anche all'interno di un gestore di
-segnali sono tutte quelle della lista riportata in
-fig.~\ref{fig:sig_safe_functions}.
+\textsl{funzioni sicure} (o più precisamente \textit{signal safe function} o
+funzioni \textit{async-signal-safe}).  Quando un segnale interrompe una
+funzione insicura ed il gestore chiama al suo interno una funzione insicura il
+sistema può dare luogo ad un comportamento indefinito, la cosa non avviene
+invece per le funzioni sicure.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -2656,7 +2649,27 @@ fig.~\ref{fig:sig_safe_functions}.
   \label{fig:sig_safe_functions}
 \end{figure}
 
-\index{funzioni!\textit{signal safe}|)}
+Tutto questo significa che la funzione che si usa come gestore di segnale deve
+essere programmata con molta cura per evirare questa evenienza e che non è
+possibile utilizzare al suo interno una qualunque funzione di sistema o di
+libreria. Oltre ovviamente ad essere rientrante rispetto all'uso di eventuali
+variabili globali del programma se si vogliono evitare questi problemi
+all'interno di un gestore di segnali si dovrà ricorrere soltanto all'uso delle
+funzioni considerate sicure.\footnote{in realtà sarebbe possibile adottare
+  come approccio alternativo quello di bloccare i segnali nel programma
+  principale tutte le volte che questo chiama funzioni insicure o utilizza
+  dati globali utilizzati anche dal gestore di segnali per poi riabilitarli
+  una volta finito; la complessità di questo approccio lo rende però
+  sostanzialmente impraticabile, ed effettivamente non impraticato.}
+
+L'elenco delle funzioni considerate sicure varia a seconda della
+implementazione utilizzata e dello standard a cui si fa riferimento. Non è
+riportata una lista specifica delle funzioni di sistema sicure per Linux, e si
+suppone pertanto che siano quelle richieste dallo standard. Secondo quanto
+richiesto dallo standard POSIX 1003.1 nella revisione del 2003, le
+``\textit{signal safe function}'' che possono essere chiamate anche
+all'interno di un gestore di segnali sono tutte quelle della lista riportata
+in fig.~\ref{fig:sig_safe_functions}.
 
 Lo standard POSIX.1-2004 modifica la lista di
 fig.~\ref{fig:sig_safe_functions} aggiungendo le funzioni \func{\_Exit} e
@@ -2678,6 +2691,45 @@ ulteriori funzioni in fig.~\ref{fig:sig_safe_functions_posix_2008}.
   \label{fig:sig_safe_functions_posix_2008}
 \end{figure}
 
+Nella successiva revisione di POSIX.1-2013 sono poi state aggiunte le
+ulteriori funzioni \func{fchdir}, \func{pthread\_kill}, \func{pthread\_self},
+\func{pthread\_sigmask}. L'ultima revisione dello standard alla data della
+scrittura di questa sezione è la POSIX.1-2016,\footnote{un elenco è comunque
+  ottenibile dalla documentazione di sistema, accessibile con \texttt{man
+    signal-safety}, da cui si sono estratti questi elenchi.} che ha aggiunto
+alle \textit{signal safe function} le ulteriori funzioni di
+fig.~\ref{fig:sig_safe_functions_posix_2016}.
+
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{14cm}
+    \func{ffs}, \func{htonl}, \func{htons}, \func{longjmp}, \func{memccpy},
+    \func{memchr}, \func{memcmp}, \func{memcpy}, \func{memmove}, \func{memset},
+    \func{siglongjmp}, \func{stpcpy}, \func{stpncpy}, \func{strcat},
+    \func{strchr}, \func{strcmp}, \func{strcpy}, \func{strcspn},
+    \func{strlen}, \func{strncat}, \func{strncmp}, \func{strncpy},
+    \func{strnlen}, \func{strpbrk}, \func{strrchr}, \func{strspn},
+    \func{strstr}, \func{strtok\_r}, \func{wcpcpy}, \func{wcpncpy},
+    \func{wcscat}, \func{wcschr}, \func{wcscmp}, \func{wcscpy},
+    \func{wcscspn}, \func{wcslen}, \func{wcsncat}, \func{wcsncmp},
+    \func{wcsncpy}, \func{wcsnlen}, \func{wcspbrk}, \func{wcsrchr},
+    \func{wcsspn}, \func{wcsstr}, \func{wcstok}, \func{wmemchr},
+    \func{wmemcmp}, \func{wmemcpy}, \func{wmemmove}, \func{wmemset}. 
+  \end{minipage} 
+  \normalsize 
+  \caption{Ulteriori funzioni sicure secondo lo standard POSIX.1-2016.}
+  \label{fig:sig_safe_functions_posix_2016}
+\end{figure}
+
+Rispetto a questi elenchi occorre precisare che prima della versione 2.24
+delle \acr{glibc} l'implementazione delle funzioni \fork{execl} ed
+\fork{execle} non era sicura, e che tuttora non lo è quella di
+\func{aio\_suspend}. Inoltre è da evitare \func{fork}, che potrebbe essere
+rimossa in future revisioni dello standard, e che già POSIX-1.2003 indicava
+come tale se usata in concorrenza con \func{pthread\_atfork}.
+
+\index{funzioni!\textit{signal safe}|)}
 
 Per questo motivo è opportuno mantenere al minimo indispensabile le operazioni
 effettuate all'interno di un gestore di segnali, qualora si debbano compiere
@@ -3948,10 +4000,13 @@ tipo \type{sigjmp\_buf}, è assolutamente identica a \func{longjmp}.
 % LocalWords:  epoch multiplexing overrun res lpthread sec nsec curr one shot
 % LocalWords:  delete stopped gdb alpha mips emulation locking ppoll epoll PGID
 % LocalWords:  pwait msgrcv msgsnd semop semtimedop runnable sigisemptyset HRT
-% LocalWords:  sigorset sigandset BOOTTIME Android request remain
+% LocalWords:  sigorset sigandset BOOTTIME Android request remain cap dell'
 
 
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"
 %%% End: 
+%  LocalWords:  IPC dest left right trampoline BNDERR MPX PKUERR MCEERR async
+%  LocalWords:  BRANCH branch HWBKPT watchpoint SECCOMP seccomp wrapper pidfd
+%  LocalWords:  fchdir sigmask safety