Ancora revisione segnali
authorSimone Piccardi <piccardi@truelite.it>
Sat, 12 Oct 2019 19:01:28 +0000 (21:01 +0200)
committerSimone Piccardi <piccardi@truelite.it>
Sat, 12 Oct 2019 19:01:28 +0000 (21:01 +0200)
errors.tex
listati/signal.c
signal.tex

index 8d7dd0f..b8b6a8f 100644 (file)
@@ -450,9 +450,17 @@ messaggio.
 % \item[\errcode{EBFONT} \textit{Bad font file format}.] 
 % \item[\errcode{ENONET} \textit{Machine is not on the network}.] 
 % \item[\errcode{ENOPKG} \textit{Package not installed}.] 
-% \item[\errcode{EREMOTEIO} \textit{Remote I/O error}.] 
-% \item[\errcode{EADV} \textit{Advertise error}.] 
-% \item[\errcode{ESRMNT} \textit{Srmount error}.] 
+% \item[\errcode{EREMOTEIO} \textit{Remote I/O error}.] si ottiene sul bus i2c
+% se non si ottiene un acknoweledgment della comunicazione con un
+% corrispondente su bus
+% \item[\errcode{EADV} \textit{Advertise error}.] errore presumibilmente
+% obsoleto, relativo a RFS
+% (\url{https://en.wikipedia.org/wiki/Remote_File_Sharing}) interfaccia per
+% filesystem remoti basta sugli stream SysV, non presente su Linux.
+% \item[\errcode{ESRMNT} \textit{Srmount error}.] errore 
+% obsoleto, relativo a RFS
+% (\url{https://en.wikipedia.org/wiki/Remote_File_Sharing}) interfaccia per
+% filesystem remoti basta sugli stream SysV, non presente su Linux.
 % \item[\errcode{ECOMM} \textit{Communication error on send}.]
 % \item[\errcode{EDOTDOT} \textit{RFS specific error}.] 
 % \item[\errcode{ENOTUNIQ} \textit{Name not unique on network}.] 
index 4e5ce1d..a8760ed 100644 (file)
@@ -1 +1 @@
-    void (*signal(int signum, void (*handler)(int)))int)
+void ( *signal(int signum, void (*handler)(int)) )(int)
index 59ef545..c408ef3 100644 (file)
@@ -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;
@@ -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}