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 è:
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 su Linux, seguendo lo standard POSIX, il
+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
In realtà \func{raise} è una funzione di libreria, che per i processi ordinari
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 è:
+\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}.
-% TODO 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
-
-% TODO c'è pure pidfd_open() (vedi https://lwn.net/Articles/789023/) per
-% ottere un pid fd pollabile aggiunta con il kernel 5.3
-
\subsection{Le funzioni di allarme ed i \textit{timer}}
\label{sec:sig_alarm_abort}
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
\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: 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 / commitdiff