%% signal.tex
%%
-%% Copyright (C) 2000-2018 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2019 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
\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;
Quelli che invece sono stati, almeno a grandi linee, standardizzati, sono i
nomi dei segnali e le costanti di preprocessore che li identificano, che sono
-tutte nella forma \texttt{SIGnome}, e sono queste che devono essere usate nei
-programmi. Come tutti gli altri nomi e le funzioni che concernono i segnali,
-esse sono definite nell'header di sistema \headfile{signal.h}.
+tutte nella forma \texttt{SIG\textsl{nome}}, e sono queste che devono essere
+usate nei programmi. Come tutti gli altri nomi e le funzioni che concernono i
+segnali, esse sono definite nell'header di sistema \headfile{signal.h}.
\begin{table}[!htb]
\footnotesize
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 è
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|}
\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
\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
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
prototipo di \func{signal} nella forma appena vista, molto più leggibile di
quanto non sia la versione originaria, che di norma è definita come:
\includecodesnip{listati/signal.c}
-questa infatti, per la poca chiarezza della sintassi del C quando si vanno a
+questa infatti, per la complessità della sintassi del C quando si vanno a
trattare puntatori a funzioni, è molto meno comprensibile. Da un confronto
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)
-e 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}.
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
L'uso di \func{signal} è soggetto a problemi di compatibilità, dato che essa
si comporta in maniera diversa per sistemi derivati da BSD o da System V. In
questi ultimi infatti la funzione è conforme al comportamento originale dei
-primi Unix in cui il gestore viene disinstallato alla sua chiamata, secondo la
+primi Unix in cui il gestore viene disinstallato alla sua chiamata secondo la
semantica inaffidabile; anche Linux seguiva questa convenzione con le vecchie
librerie del C come la \acr{libc4} e la \acr{libc5}.\footnote{nelle
- \acr{libc5} esiste però la possibilità di includere \file{bsd/signal.h} al
- posto di \headfile{signal.h}, nel qual caso la funzione \func{signal} viene
+ \acr{libc5} esisteva però la possibilità di includere \file{bsd/signal.h} al
+ posto di \headfile{signal.h}, nel qual caso la funzione \func{signal} era
ridefinita per seguire la semantica affidabile usata da BSD.}
Al contrario BSD segue la semantica affidabile, non disinstallando il gestore
comportamento della versione originale della funzione, il cui uso è deprecato
per i motivi visti in sez.~\ref{sec:sig_semantics}, può essere ottenuto
chiamando \funcm{sysv\_signal}, una volta che si sia definita la macro
-\macro{\_XOPEN\_SOURCE}. In generale, per evitare questi problemi, l'uso di
-\func{signal}, che tra l'altro ha un comportamento indefinito in caso di
-processo multi-\textit{thread}, è da evitare: tutti i nuovi programmi devono
+\macro{\_XOPEN\_SOURCE}.
+
+In generale, per evitare questi problemi e per le possibili differenze nella
+semantica fra versioni diverse di kernel, l'uso di \func{signal} è sempre da
+evitare, visto che tra l'altro la funzione ha un comportamento indefinito in
+caso di processi multi-\textit{thread}; l'unico utilizzo sicuro della funzione
+è con \const{SIG\_IGN} e \const{SIG\_DFL}, in tutti gli altri casi si deve
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.
+Infine si deve 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}
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{sec:thread_signal}) 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}
$>0$ & Il segnale è mandato al processo con \ids{PID} uguale
a \param{pid}.\\
0 & Il segnale è mandato ad ogni processo del \textit{process group}
- del chiamante.\\
+ (vedi sez.~\ref{sec:sess_proc_group}) del chiamante.\\
$-1$ & Il segnale è mandato ad ogni processo (eccetto \cmd{init}).\\
$<-1$& Il segnale è mandato ad ogni processo del \textit{process group}
con \ids{PGID} uguale a $|\param{pid}|$.\\
per questo argomento. Si tenga conto però che il sistema ricicla i \ids{PID}
(come accennato in sez.~\ref{sec:proc_pid}) per cui l'esistenza di un processo
non significa che esso sia realmente quello a cui si intendeva mandare il
-segnale.
+segnale (torneremo su questo in sez.~\ref{sec:sig_pid_fd}).
Indipendentemente dalla funzione specifica che viene usata solo
l'amministratore può inviare un segnale ad un processo qualunque, in tutti gli
altri casi l'\ids{UID} reale o l'\ids{UID} effettivo del processo chiamante
devono corrispondere all'\ids{UID} reale o all'\ids{UID} salvato della
-destinazione. Fa eccezione il caso in cui il segnale inviato sia
+destinazione.\footnote{questo a partire dal kernel 1.3.78, seguendo lo
+ standard POSIX.1; in precedenza il comportamento era diverso, gli
+ interessati alla storia possono consultare la pagina di manuale della
+ funzione.} Fa eccezione il caso in cui il segnale inviato sia
\signal{SIGCONT}, nel quale occorre anche che entrambi i processi appartengano
alla stessa sessione.
saranno chiusi ed i buffer scaricati su disco. Non verranno invece eseguite le
eventuali funzioni registrate con \func{atexit} e \func{on\_exit}.
-
-
-
\subsection{Le funzioni di allarme ed i \textit{timer}}
\label{sec:sig_alarm_abort}
corrisponde al \textit{clock time}). La scadenza di questo timer provoca
l'emissione di \signal{SIGALRM};
\item un \textit{virtual timer} che calcola il tempo di processore usato dal
- processo in user space (che corrisponde all'\textit{user time}). La scadenza
- di questo timer provoca l'emissione di \signal{SIGVTALRM};
+ processo in \textit{user space} (che corrisponde all'\textit{user time}). La
+ scadenza di questo timer provoca l'emissione di \signal{SIGVTALRM};
\item un \textit{profiling timer} che calcola la somma dei tempi di processore
- utilizzati direttamente dal processo in user space, e dal kernel nelle
- \textit{system call} ad esso relative (che corrisponde a quello che in
+ utilizzati direttamente dal processo in \textit{user space}, e dal kernel
+ nelle \textit{system call} ad esso relative (che corrisponde a quello che in
sez.~\ref{sec:sys_unix_time} abbiamo chiamato \textit{processor time}). La
scadenza di questo timer provoca l'emissione di \signal{SIGPROF}.
\end{itemize*}
richiesto.
Ma in un sistema multitasking un ciclo di attesa è solo un inutile spreco di
-tempo di processore, dato che altri programmi possono essere eseguiti nel
+tempo di processore dato che altri programmi possono essere eseguiti nel
frattempo, per questo ci sono delle apposite funzioni che permettono di
mantenere un processo in attesa per il tempo voluto, senza impegnare il
processore. In pratica si tratta di funzioni che permettono di portare
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
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.
% https://git.kernel.org/linus/d6ed449afdb38f89a7b38ec50e367559e1b8f71f
% change reverted, vedi: https://lwn.net/Articles/752757/
-
% NOTE: dal 3.0 anche i cosiddetti Posix Alarm Timers, con
% CLOCK_REALTIME_ALARM vedi http://lwn.net/Articles/429925/
% TODO: dal 3.10 anche CLOCK_TAI
+% TODO seguire l'evoluzione delle nuove syscall per il problema del 2038,
+% iniziate ad entrare nel kernel dal 5.1, vedi
+% https://lwn.net/Articles/776435/, https://lwn.net/Articles/782511/,
+% https://git.kernel.org/linus/b1b988a6a035
+
Per poter utilizzare queste funzionalità la \acr{glibc} richiede che la
macro \macro{\_POSIX\_C\_SOURCE} sia definita ad un valore maggiore o uguale
di \texttt{199309L} (vedi sez.~\ref{sec:intro_gcc_glibc_std}), inoltre i
\itindend{POSIX~Timer~API}
-
\subsection{Ulteriori funzioni di gestione}
\label{sec:sig_specific_features}
% argomento a priorità IDLE (fare quando non resta niente altro da trattare)
+\subsection{I \textit{pidfd} e l'invio di segnali \textit{race-free}}
+\label{sec:sig_pid_fd}
+
+
+% TODO: trattare (qui?) 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/
+% oppure sopra in "Ulteriori funzioni di gestione"
+
+% 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
+
+
+
+
% LocalWords: kernel POSIX timer shell control ctrl kill raise signal handler
% LocalWords: reliable unreliable fig race condition sez struct process table
% LocalWords: delivered pending scheduler sigpending l'I suspend SIGKILL wait
projects / gapil.git / blobdiff