%% signal.tex
%%
-%% Copyright (C) 2000-2015 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",
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
\end{table}
-Si inoltre noti come \const{SIGCONT} sia l'unico segnale a non avere
+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 \const{SIGSTOP} e \const{SIGKILL} si distinguono da
+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 \const{NSIG} (e tiene
+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
numerico assegnato all'ultimo segnale definito. La descrizione dettagliata
avuto successo.
\item[\signald{SIGURG}] Questo segnale è inviato quando arrivano dei dati
- urgenti o \itindex{out-of-band} \textit{out-of-band} su di un
- socket; per maggiori dettagli al proposito si veda
- sez.~\ref{sec:TCP_urgent_data}.
+ urgenti o \textit{out-of-band} su di un socket; per maggiori dettagli al
+ proposito si veda sez.~\ref{sec:TCP_urgent_data}.
\item[\signald{SIGPOLL}] Questo segnale è definito nella standard POSIX.1-2001,
ed è equivalente a \signal{SIGIO} che invece deriva da BSD. Su Linux è
La maggior pare dei programmi non hanno necessità di intercettare il
segnale, in quanto esso è completamente trasparente rispetto all'esecuzione
che riparte senza che il programma noti niente. Si possono installare dei
- gestori per far si che un programma produca una qualche azione speciale
+ gestori per far sì che un programma produca una qualche azione speciale
se viene fermato e riavviato, come per esempio riscrivere un prompt, o
inviare un avviso.
Quando si mette in esecuzione un nuovo programma con \func{exec} (si ricordi
quanto detto in sez.~\ref{sec:proc_exec}) tutti i segnali per i quali è stato
-installato un gestore vengono reimpostati a \const{SIG\_DFL}. Non ha più
+installato un gestore vengono reimpostati a \constd{SIG\_DFL}. Non ha più
senso infatti fare riferimento a funzioni definite nel programma originario,
che non sono presenti nello spazio di indirizzi del nuovo programma.
Si noti che questo vale solo per le azioni per le quali è stato installato un
gestore, viene mantenuto invece ogni eventuale impostazione dell'azione a
-\const{SIG\_IGN}. Questo permette ad esempio alla shell di impostare ad
+\constd{SIG\_IGN}. Questo permette ad esempio alla shell di impostare ad
\const{SIG\_IGN} le risposte per \signal{SIGINT} e \signal{SIGQUIT} per i
programmi eseguiti in background, che altrimenti sarebbero interrotti da una
successiva pressione di \texttt{C-c} o \texttt{C-y}.
Per quanto riguarda il comportamento di tutte le altre \textit{system call} si
-danno sostanzialmente due casi, a seconda che esse siano
-\index{system~call~lente} \textsl{lente} (\textit{slow}) o \textsl{veloci}
-(\textit{fast}). La gran parte di esse appartiene a quest'ultima categoria,
-che non è influenzata dall'arrivo di un segnale. Esse sono dette
-\textsl{veloci} in quanto la loro esecuzione è sostanzialmente immediata. La
-risposta al segnale viene sempre data dopo che la \textit{system call} è stata
-completata, in quanto attendere per eseguire un gestore non comporta nessun
-inconveniente.
+danno sostanzialmente due casi, a seconda che esse siano \textsl{lente}
+(\textit{slow}) o \textsl{veloci} (\textit{fast}). La gran parte di esse
+appartiene a quest'ultima categoria, che non è influenzata dall'arrivo di un
+segnale. Esse sono dette \textsl{veloci} in quanto la loro esecuzione è
+sostanzialmente immediata. La risposta al segnale viene sempre data dopo che
+la \textit{system call} è stata completata, in quanto attendere per eseguire
+un gestore non comporta nessun inconveniente.
+
+\index{system~call~lente|(}
In alcuni casi però alcune \textit{system call} possono bloccarsi
-indefinitamente e per questo motivo vengono chiamate \textsl{lente}
-\index{system~call~lente} o \textsl{bloccanti}. In questo caso non si può
-attendere la conclusione della \textit{system call}, perché questo renderebbe
-impossibile una risposta pronta al segnale, per cui il gestore viene eseguito
-prima che la \textit{system call} sia ritornata. Un elenco dei casi in cui si
-presenta questa situazione è il seguente:
+indefinitamente e per questo motivo vengono chiamate \textsl{lente} o
+\textsl{bloccanti}. In questo caso non si può attendere la conclusione della
+\textit{system call}, perché questo renderebbe impossibile una risposta pronta
+al segnale, per cui il gestore viene eseguito prima che la \textit{system
+ call} sia ritornata. Un elenco dei casi in cui si presenta questa
+situazione è il seguente:
\begin{itemize*}
\item la lettura da file che possono bloccarsi in attesa di dati non ancora
presenti (come per certi file di dispositivo, i socket o le \textit{pipe});
essere riavvolto);
\item le operazioni eseguite con \func{ioctl} che non è detto possano essere
eseguite immediatamente;
-\item le funzioni di intercomunicazione fra processi (vedi cap.~\ref{cha:IPC})
- che si bloccano in attesa di risposte da altri processi;
-\item la funzione \func{pause} (vedi sez.~\ref{sec:sig_pause_sleep}) e le
- analoghe \func{sigsuspend}, \func{sigtimedwait}, e \func{sigwaitinfo} (vedi
- sez.~\ref{sec:sig_real_time}), usate appunto per attendere l'arrivo di un
- segnale;
-\item le funzioni associate al \textit{file locking} (vedi
+\item l'uso di funzioni di intercomunicazione fra processi (vedi
+ cap.~\ref{cha:IPC}) che si bloccano in attesa di risposte da altri processi;
+\item l'uso della funzione \func{pause} (vedi sez.~\ref{sec:sig_pause_sleep})
+ e le analoghe \func{sigsuspend}, \func{sigtimedwait}, e \func{sigwaitinfo}
+ (vedi sez.~\ref{sec:sig_real_time}), usate appunto per attendere l'arrivo di
+ un segnale;
+\item l'uso delle funzioni associate al \textit{file locking} (vedi
sez.~\ref{sec:file_locking})
-\item la funzione \func{wait} e le analoghe funzioni di attesa se nessun
- processo figlio è ancora terminato.
+\item l'uso della funzione \func{wait} e le analoghe funzioni di attesa se
+ nessun processo figlio è ancora terminato.
\end{itemize*}
In questo caso si pone il problema di cosa fare una volta che il gestore sia
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 le \acr{glibc} provvedono una macro
+un errore comune, tanto che la \acr{glibc} provvede una macro
\code{TEMP\_FAILURE\_RETRY(expr)} che esegue l'operazione automaticamente,
ripetendo l'esecuzione dell'espressione \var{expr} fintanto che il risultato
non è diverso dall'uscita con un errore \errcode{EINTR}.
possibilità di eseguire azioni specifiche all'occorrenza di questa particolare
condizione.
-Linux e le \acr{glibc} consentono di utilizzare entrambi gli approcci,
+Linux e la \acr{glibc} consentono di utilizzare entrambi gli approcci,
attraverso una opportuna opzione di \func{sigaction} (vedi
sez.~\ref{sec:sig_sigaction}). È da chiarire comunque che nel caso di
interruzione nel mezzo di un trasferimento parziale di dati, le \textit{system
possa essere stato richiesto il riavvio automatico, queste funzioni sono:
\begin{itemize*}
-\item le funzioni di attesa di un segnale, come \func{pause} (vedi
- sez.~\ref{sec:sig_pause_sleep}), \func{sigsuspend}, \func{sigtimedwait}, e
+\item le funzioni di attesa di un segnale: \func{pause} (vedi
+ sez.~\ref{sec:sig_pause_sleep}) o \func{sigsuspend}, \func{sigtimedwait}, e
\func{sigwaitinfo} (vedi sez.~\ref{sec:sig_real_time}).
-\item le funzioni di attesa dell'\textit{I/O multiplexing}, come
- \func{select}, \func{pselect}, \func{poll}, \func{ppoll}, \func{epoll\_wait}
- e \func{epoll\_pwait} (vedi sez.~\ref{sec:file_multiplexing}).
+\item le funzioni di attesa dell'\textit{I/O multiplexing} (vedi
+ sez.~\ref{sec:file_multiplexing}) come \func{select}, \func{pselect},
+ \func{poll}, \func{ppoll}, \func{epoll\_wait} e \func{epoll\_pwait}.
\item le funzioni del System V IPC che prevedono attese: \func{msgrcv},
\func{msgsnd} (vedi sez.~\ref{sec:ipc_sysv_mq}), \func{semop} e
\func{semtimedop} (vedi sez.~\ref{sec:ipc_sysv_sem}).
-\item le funzioni di attesa di un processo: \func{usleep}, \func{nanosleep}
- (vedi sez.~\ref{sec:sig_pause_sleep}) e \func{clock\_nanosleep} (vedi
- sez.~\ref{sec:sig_timer_adv}).
+\item le funzioni per la messa in attesa di un processo come \func{usleep},
+ \func{nanosleep} (vedi sez.~\ref{sec:sig_pause_sleep}) e
+ \func{clock\_nanosleep} (vedi sez.~\ref{sec:sig_timer_adv}).
\item le funzioni che operano sui socket quando è stato impostato un
\textit{timeout} sugli stessi con \func{setsockopt} (vedi
sez.~\ref{sec:sock_generic_options}) ed in particolare \func{accept},
\end{itemize*}
+\index{system~call~lente|)}
+
\subsection{L'installazione di un gestore}
\label{sec:sig_signal}
}
{La funzione ritorna il precedente gestore in caso di successo in caso di
- successo e \const{SIG\_ERR} per un errore, nel qual caso \var{errno}
+ successo e \constd{SIG\_ERR} per un errore, nel qual caso \var{errno}
assumerà il valore:
\begin{errlist}
\item[\errcode{EINVAL}] il numero di segnale \param{signum} non è valido.
In questa definizione per l'argomento \param{handler} che indica il gestore da
installare si è usato un tipo di dato, \type{sighandler\_t}, che è una
-estensione GNU, definita dalle \acr{glibc}, che permette di riscrivere il
+estensione GNU, definita dalla \acr{glibc}, che permette di riscrivere il
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}
ridefinita per seguire la semantica affidabile usata da BSD.}
Al contrario BSD segue la semantica affidabile, non disinstallando il gestore
-e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo delle
+e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo della
\acr{glibc} dalla versione 2 anche Linux è passato a questo comportamento. Il
comportamento della versione originale della funzione, il cui uso è deprecato
per i motivi visti in sez.~\ref{sec:sig_semantics}, può essere ottenuto
\hline
\hline
$>0$ & Il segnale è mandato al processo con \ids{PID} uguale
- a \param{pid}.\\
- 0 & Il segnale è mandato ad ogni processo del \itindex{process~group}
- \textit{process group} del chiamante.\\
+ a \param{pid}.\\
+ 0 & Il segnale è mandato ad ogni processo del \textit{process group}
+ del chiamante.\\
$-1$ & Il segnale è mandato ad ogni processo (eccetto \cmd{init}).\\
$<-1$& Il segnale è mandato ad ogni processo del \textit{process group}
- \itindex{process~group} con \ids{PGID} uguale
- a $|\param{pid}|$.\\
+ con \ids{PGID} uguale a $|\param{pid}|$.\\
\hline
\end{tabular}
\caption{Valori dell'argomento \param{pid} per la funzione
\begin{funcproto}{
\fhead{signal.h}
\fdecl{int killpg(pid\_t pidgrp, int signal)}
-\fdesc{Invia un segnale ad un \itindex{process~group} \textit{process group}.}
+\fdesc{Invia un segnale ad un \textit{process group}.}
}
{ La funzione ritorna $0$ in caso di successo e $-1$ per un errore, e gli
\end{funcproto}
-La funzione invia il segnale \param{signal} al \itindex{process~group}
-\textit{process group} il cui \acr{PGID} (vedi sez.~\ref{sec:sess_proc_group})
-è indicato dall'argomento \param{pidgrp}, che deve essere un intero
-positivo. Il suo utilizzo è sostanzialmente equivalente all'esecuzione di
-\code{kill(-pidgrp, signal)}.
+La funzione invia il segnale \param{signal} al \textit{process group} il cui
+\acr{PGID} (vedi sez.~\ref{sec:sess_proc_group}) è indicato
+dall'argomento \param{pidgrp}, che deve essere un intero positivo. Il suo
+utilizzo è sostanzialmente equivalente all'esecuzione di \code{kill(-pidgrp,
+ signal)}.
Oltre alle precedenti funzioni di base, vedremo più avanti che esistono altre
funzioni per inviare segnali generici, come \func{sigqueue} per i segnali
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}
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*}
\textbf{Valore} & \textbf{Timer} \\
\hline
\hline
- \const{ITIMER\_REAL} & \textit{real-time timer}\\
- \const{ITIMER\_VIRTUAL} & \textit{virtual timer}\\
- \const{ITIMER\_PROF} & \textit{profiling timer}\\
+ \constd{ITIMER\_REAL} & \textit{real-time timer}\\
+ \constd{ITIMER\_VIRTUAL} & \textit{virtual timer}\\
+ \constd{ITIMER\_PROF} & \textit{profiling timer}\\
\hline
\end{tabular}
\caption{Valori dell'argomento \param{which} per la funzione
L'uso di \func{setitimer} consente dunque un controllo completo di tutte le
caratteristiche dei timer, ed in effetti la stessa \func{alarm}, benché
definita direttamente nello standard POSIX.1, può a sua volta essere espressa
-in termini di \func{setitimer}, come evidenziato dal manuale delle \acr{glibc}
+in termini di \func{setitimer}, come evidenziato dal manuale della \acr{glibc}
\cite{GlibcMan} che ne riporta la definizione mostrata in
fig.~\ref{fig:sig_alarm_def}.\footnote{questo comporta anche che non è il caso
di mescolare chiamate ad \func{abort} e a \func{setitimer}.}
L'uso del contatore dei \textit{jiffies}, un intero a 32 bit nella maggior
parte dei casi, comportava inoltre l'impossibilità di specificare tempi molto
-lunghi. superiori al valore della costante \const{MAX\_SEC\_IN\_JIFFIES},
+lunghi. superiori al valore della costante \constd{MAX\_SEC\_IN\_JIFFIES},
pari, nel caso di default di un valore di \const{HZ} di 250, a circa 99 giorni
e mezzo. Con il cambiamento della rappresentazione effettuato nel kernel
2.6.16 questo problema è scomparso e con l'introduzione dei timer ad alta
Una seconda causa di potenziali ritardi è che il segnale viene generato alla
scadenza del timer, ma poi deve essere consegnato al processo; se quest'ultimo
-è attivo (questo è sempre vero per \const{ITIMER\_VIRT}) la consegna è
+è attivo (questo è sempre vero per \const{ITIMER\_VIRTUAL}) la consegna è
immediata, altrimenti può esserci un ulteriore ritardo che può variare a
seconda del carico del sistema.
stato consegnato. In questo caso, per il comportamento dei segnali descritto
in sez.~\ref{sec:sig_sigchld}, un solo segnale sarà consegnato. Per questo
oggi l'uso di questa funzione è deprecato a favore degli
-\textit{high-resolution timer} e della cosiddetta \itindex{POSIX~Timer~API}
-\textit{POSIX Timer API}, che tratteremo in sez.~\ref{sec:sig_timer_adv}.
+\textit{high-resolution timer} e della cosiddetta \textit{POSIX Timer API},
+che tratteremo in sez.~\ref{sec:sig_timer_adv}.
Dato che sia \func{alarm} che \func{setitimer} non consentono di leggere il
valore corrente di un timer senza modificarlo, è possibile usare la funzione
quella dell'esempio che vedremo in sez.~\ref{sec:sig_example}. In tal caso
mescolare chiamate di \func{alarm} e \func{sleep} o modificare l'azione
associata \signal{SIGALRM}, può portare a dei risultati indefiniti. Nel caso
-delle \acr{glibc} è stata usata una implementazione completamente indipendente
+della \acr{glibc} è stata usata una implementazione completamente indipendente
e questi problemi non ci sono, ma un programma portabile non può fare questa
assunzione.
La granularità di \func{sleep} permette di specificare attese soltanto in
secondi, per questo sia sotto BSD4.3 che in SUSv2 è stata definita un'altra
funzione con una precisione teorica del microsecondo. I due standard hanno
-delle definizioni diverse, ma le \acr{glibc} seguono (secondo la pagina di
-manuale almeno dalla versione 2.2.2) seguono quella di SUSv2 per cui la
+delle definizioni diverse, ma la \acr{glibc} segue (secondo la pagina di
+manuale almeno dalla versione 2.2.2) quella di SUSv2 per cui la
funzione \funcd{usleep} (dove la \texttt{u} è intesa come sostituzione di
$\mu$), ha il seguente prototipo:
POSIX.1 ha ridefinito completamente l'interfaccia per la gestione dei segnali,
rendendola molto più flessibile e robusta, anche se leggermente più complessa.
-La funzione di sistema principale prevista dall'interfaccia POSIX.1 per i
-segnali è \funcd{sigaction}. Essa ha sostanzialmente lo stesso uso di
-\func{signal}, permette cioè di specificare le modalità con cui un segnale può
-essere gestito da un processo. Il suo prototipo è:
+La principale funzione di sistema prevista dall'interfaccia POSIX.1 per la
+gestione dei segnali è \funcd{sigaction}. Essa ha sostanzialmente lo stesso
+uso di \func{signal}, permette cioè di specificare le modalità con cui un
+segnale può essere gestito da un processo. Il suo prototipo è:
\begin{funcproto}{
\fhead{signal.h}
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{SA\_NOCLDSTOP}& Se il segnale è \signal{SIGCHLD} allora non deve
- essere notificato quando il processo figlio viene
- fermato da uno dei segnali \signal{SIGSTOP},
- \signal{SIGTSTP}, \signal{SIGTTIN} o
- \signal{SIGTTOU}, questo flag ha significato solo
- quando si imposta un gestore per \signal{SIGCHLD}.\\
- \const{SA\_NOCLDWAIT}& Se il segnale è \signal{SIGCHLD} e si richiede di
- ignorare il segnale con \const{SIG\_IGN} allora i
- processi figli non diventano \textit{zombie} quando
- terminano; questa funzionalità è stata introdotta
- nel kernel 2.6 e va a modificare il comportamento
- di \func{waitpid} come illustrato in
- sez.~\ref{sec:proc_wait}, se si installa un gestore
- con questo flag attivo il segnale \signal{SIGCHLD}
- viene comunque generato.\\
- \const{SA\_NODEFER} & Evita che il segnale corrente sia bloccato durante
- l'esecuzione del gestore.\\
- \const{SA\_NOMASK} & Nome obsoleto e sinonimo non standard di
- \const{SA\_NODEFER}, non deve essere più
- utilizzato.\\
- \const{SA\_ONESHOT} & Nome obsoleto e sinonimo non standard di
- \const{SA\_RESETHAND}, non deve essere più
- utilizzato.\\
- \const{SA\_ONSTACK} & Stabilisce l'uso di uno \textit{stack} alternativo
- per l'esecuzione del gestore (vedi
- sez.~\ref{sec:sig_specific_features}).\\
- \const{SA\_RESETHAND}& Ristabilisce l'azione per il segnale al valore
- predefinito una volta che il gestore è stato
- lanciato, riproduce cioè il comportamento della
- semantica inaffidabile.\\
- \const{SA\_RESTART} & Riavvia automaticamente le \textit{slow system
- call} quando vengono interrotte dal suddetto
- segnale, riproduce cioè il comportamento standard
- di BSD.\index{system~call~lente}\\
- \const{SA\_SIGINFO} & Deve essere specificato quando si vuole usare un
- gestore in forma estesa usando
- \var{sa\_sigaction} al posto di
- \var{sa\_handler}.\\
+ \constd{SA\_NOCLDSTOP}& Se il segnale è \signal{SIGCHLD} allora non deve
+ essere notificato quando il processo figlio viene
+ fermato da uno dei segnali \signal{SIGSTOP},
+ \signal{SIGTSTP}, \signal{SIGTTIN} o
+ \signal{SIGTTOU}, questo flag ha significato solo
+ quando si imposta un gestore per \signal{SIGCHLD}.\\
+ \constd{SA\_NOCLDWAIT}& Se il segnale è \signal{SIGCHLD} e si richiede di
+ ignorare il segnale con \const{SIG\_IGN} allora i
+ processi figli non diventano \textit{zombie} quando
+ terminano; questa funzionalità è stata introdotta
+ nel kernel 2.6 e va a modificare il comportamento
+ di \func{waitpid} come illustrato in
+ sez.~\ref{sec:proc_wait}, se si installa un gestore
+ con questo flag attivo il segnale \signal{SIGCHLD}
+ viene comunque generato.\\
+ \constd{SA\_NODEFER} & Evita che il segnale corrente sia bloccato durante
+ l'esecuzione del gestore.\\
+ \constd{SA\_NOMASK} & Nome obsoleto e sinonimo non standard di
+ \const{SA\_NODEFER}, non deve essere più
+ utilizzato.\\
+ \constd{SA\_ONESHOT} & Nome obsoleto e sinonimo non standard di
+ \const{SA\_RESETHAND}, non deve essere più
+ utilizzato.\\
+ \constd{SA\_ONSTACK} & Stabilisce l'uso di uno \textit{stack} alternativo
+ per l'esecuzione del gestore (vedi
+ sez.~\ref{sec:sig_specific_features}).\\
+ \constd{SA\_RESETHAND}& Ristabilisce l'azione per il segnale al valore
+ predefinito una volta che il gestore è stato
+ lanciato, riproduce cioè il comportamento della
+ semantica inaffidabile.\\
+ \constd{SA\_RESTART} & Riavvia automaticamente le \textit{slow system
+ call} quando vengono interrotte dal suddetto
+ segnale, riproduce cioè il comportamento standard
+ di BSD.\\
+ \constd{SA\_SIGINFO} & Deve essere specificato quando si vuole usare un
+ gestore in forma estesa usando
+ \var{sa\_sigaction} al posto di
+ \var{sa\_handler}.\\
\hline
\end{tabular}
\caption{Valori del campo \var{sa\_flag} della struttura \struct{sigaction}.}
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{SI\_USER} & Generato da \func{kill} o \func{raise} o affini.\\
- \const{SI\_KERNEL} & Inviato direttamente dal kernel.\\
- \const{SI\_QUEUE} & Inviato con \func{sigqueue} (vedi
- sez.~\ref{sec:sig_real_time}).\\
- \const{SI\_TIMER} & Scadenza di un\itindex{POSIX~Timer~API} \textit{POSIX
- timer} (vedi sez.~\ref{sec:sig_timer_adv}).\\
- \const{SI\_MESGQ} & Inviato al cambiamento di stato di una coda di
- messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}),
- introdotto con il kernel 2.6.6.\\
- \const{SI\_ASYNCIO}& Una operazione di I/O asincrono (vedi
- sez.~\ref{sec:file_asyncronous_io}) è stata
- completata.\\
- \const{SI\_SIGIO} & Segnale di \signal{SIGIO} da una coda (vedi
- sez.~\ref{sec:file_asyncronous_operation}).\\
- \const{SI\_TKILL} & Inviato da \func{tkill} o \func{tgkill} (vedi
- sez.~\ref{cha:thread_xxx}), introdotto con il kernel
- 2.4.19.\\
+ \constd{SI\_USER} & Generato da \func{kill} o \func{raise} o affini.\\
+ \constd{SI\_KERNEL} & Inviato direttamente dal kernel.\\
+ \constd{SI\_QUEUE} & Inviato con \func{sigqueue} (vedi
+ sez.~\ref{sec:sig_real_time}).\\
+ \constd{SI\_TIMER} & Scadenza di un \textit{POSIX timer} (vedi
+ sez.~\ref{sec:sig_timer_adv}).\\
+ \constd{SI\_MESGQ} & Inviato al cambiamento di stato di una coda di
+ messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}),
+ introdotto con il kernel 2.6.6.\\
+ \constd{SI\_ASYNCIO}& Una operazione di I/O asincrono (vedi
+ sez.~\ref{sec:file_asyncronous_io}) è stata
+ completata.\\
+ \constd{SI\_SIGIO} & Segnale di \signal{SIGIO} da una coda (vedi
+ sez.~\ref{sec:file_asyncronous_operation}).\\
+ \constd{SI\_TKILL} & Inviato da \func{tkill} o \func{tgkill} (vedi
+ sez.~\ref{cha:thread_xxx}), introdotto con il kernel
+ 2.4.19.\\
\hline
\end{tabular}
\caption{Valori del campo \var{si\_code} della struttura \struct{sigaction}
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{ILL\_ILLOPC} & Codice di operazione illegale.\\
- \const{ILL\_ILLOPN} & Operando illegale.\\
- \const{ILL\_ILLADR} & Modo di indirizzamento illegale.\\
- \const{ILL\_ILLTRP} & Trappola di processore illegale.\\
- \const{ILL\_PRVOPC} & Codice di operazione privilegiato.\\
- \const{ILL\_PRVREG} & Registro privilegiato.\\
- \const{ILL\_COPROC} & Errore del coprocessore.\\
- \const{ILL\_BADSTK} & Errore nello stack interno.\\
+ \constd{ILL\_ILLOPC} & Codice di operazione illegale.\\
+ \constd{ILL\_ILLOPN} & Operando illegale.\\
+ \constd{ILL\_ILLADR} & Modo di indirizzamento illegale.\\
+ \constd{ILL\_ILLTRP} & Trappola di processore illegale.\\
+ \constd{ILL\_PRVOPC} & Codice di operazione privilegiato.\\
+ \constd{ILL\_PRVREG} & Registro privilegiato.\\
+ \constd{ILL\_COPROC} & Errore del coprocessore.\\
+ \constd{ILL\_BADSTK} & Errore nello stack interno.\\
\hline
- \const{FPE\_INTDIV} & Divisione per zero intera.\\
- \const{FPE\_INTOVF} & Overflow intero.\\
- \const{FPE\_FLTDIV} & Divisione per zero in virgola mobile.\\
- \const{FPE\_FLTOVF} & Overflow in virgola mobile.\\
- \const{FPE\_FLTUND} & Underflow in virgola mobile.\\
- \const{FPE\_FLTRES} & Risultato in virgola mobile non esatto.\\
- \const{FPE\_FLTINV} & Operazione in virgola mobile non valida.\\
- \const{FPE\_FLTSUB} & Mantissa? fuori intervallo.\\
+ \constd{FPE\_INTDIV} & Divisione per zero intera.\\
+ \constd{FPE\_INTOVF} & Overflow intero.\\
+ \constd{FPE\_FLTDIV} & Divisione per zero in virgola mobile.\\
+ \constd{FPE\_FLTOVF} & Overflow in virgola mobile.\\
+ \constd{FPE\_FLTUND} & Underflow in virgola mobile.\\
+ \constd{FPE\_FLTRES} & Risultato in virgola mobile non esatto.\\
+ \constd{FPE\_FLTINV} & Operazione in virgola mobile non valida.\\
+ \constd{FPE\_FLTSUB} & Mantissa? fuori intervallo.\\
\hline
- \const{SEGV\_MAPERR} & Indirizzo non mappato.\\
- \const{SEGV\_ACCERR} & Permessi non validi per l'indirizzo.\\
+ \constd{SEGV\_MAPERR} & Indirizzo non mappato.\\
+ \constd{SEGV\_ACCERR} & Permessi non validi per l'indirizzo.\\
\hline
- \const{BUS\_ADRALN} & Allineamento dell'indirizzo non valido.\\
- \const{BUS\_ADRERR} & Indirizzo fisico inesistente.\\
- \const{BUS\_OBJERR} & Errore hardware sull'indirizzo.\\
+ \constd{BUS\_ADRALN} & Allineamento dell'indirizzo non valido.\\
+ \constd{BUS\_ADRERR} & Indirizzo fisico inesistente.\\
+ \constd{BUS\_OBJERR} & Errore hardware sull'indirizzo.\\
\hline
- \const{TRAP\_BRKPT} & Breakpoint sul processo.\\
- \const{TRAP\_TRACE} & Trappola di tracciamento del processo.\\
+ \constd{TRAP\_BRKPT} & Breakpoint sul processo.\\
+ \constd{TRAP\_TRACE} & Trappola di tracciamento del processo.\\
\hline
\constd{CLD\_EXITED} & Il figlio è uscito.\\
\constd{CLD\_KILLED} & Il figlio è stato terminato.\\
\constd{CLD\_STOPPED} & Il figlio è stato fermato.\\
\constd{CLD\_CONTINUED}& Il figlio è ripartito.\\
\hline
- \const{POLL\_IN} & Disponibili dati in ingresso.\\
- \const{POLL\_OUT} & Spazio disponibile sul buffer di uscita.\\
- \const{POLL\_MSG} & Disponibili messaggi in ingresso.\\
- \const{POLL\_ERR} & Errore di I/O.\\
- \const{POLL\_PRI} & Disponibili dati di alta priorità in ingresso.\\
- \const{POLL\_HUP} & Il dispositivo è stato disconnesso.\\
+ \constd{POLL\_IN} & Disponibili dati in ingresso.\\
+ \constd{POLL\_OUT} & Spazio disponibile sul buffer di uscita.\\
+ \constd{POLL\_MSG} & Disponibili messaggi in ingresso.\\
+ \constd{POLL\_ERR} & Errore di I/O.\\
+ \constd{POLL\_PRI} & Disponibili dati di alta priorità in ingresso.\\
+ \constd{POLL\_HUP} & Il dispositivo è stato disconnesso.\\
\hline
\end{tabular}
\caption{Valori del campo \var{si\_code} della struttura \struct{sigaction}
\label{tab:sig_si_code_special}
\end{table}
-Il resto della struttura \struct{siginfo\_t} è definito come una
-\dirct{union} ed i valori eventualmente presenti dipendono dal segnale
-ricevuto, così \signal{SIGCHLD} ed i segnali \textit{real-time} (vedi
+Il resto della struttura \struct{siginfo\_t} è definito come una \dirct{union}
+ed i valori eventualmente presenti dipendono dal segnale ricevuto, così
+\signal{SIGCHLD} ed i segnali \textit{real-time} (vedi
sez.~\ref{sec:sig_real_time}) inviati tramite \func{kill} avvalorano
\var{si\_pid} e \var{si\_uid} coi valori corrispondenti al processo che ha
emesso il segnale, \signal{SIGCHLD} avvalora anche i campi \var{si\_status},
\signal{SIGFPE}, \signal{SIGSEGV} e \signal{SIGBUS} avvalorano \var{si\_addr}
con l'indirizzo in cui è avvenuto l'errore, \signal{SIGIO} (vedi
sez.~\ref{sec:file_asyncronous_io}) avvalora \var{si\_fd} con il numero del
-file descriptor e \var{si\_band} per i \itindex{out-of-band} dati urgenti
-(vedi sez.~\ref{sec:TCP_urgent_data}) su un socket, il segnale inviato alla
-scadenza di un \itindex{POSIX~Timer~API} POSIX timer (vedi
-sez.~\ref{sec:sig_timer_adv}) avvalora i campi \var{si\_timerid} e
-\var{si\_overrun}.
+file descriptor e \var{si\_band} per i dati urgenti (vedi
+sez.~\ref{sec:TCP_urgent_data}) su un socket, il segnale inviato alla scadenza
+di un POSIX timer (vedi sez.~\ref{sec:sig_timer_adv}) avvalora i campi
+\var{si\_timerid} e \var{si\_overrun}.
Benché sia possibile usare nello stesso programma sia \func{sigaction} che
\func{signal} occorre molta attenzione, in quanto le due funzioni possono
\label{sec:sig_sigmask}
\index{maschera dei segnali|(}
-Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like
-permettono di bloccare temporaneamente (o di eliminare completamente,
-impostando come azione \const{SIG\_IGN}) la consegna dei segnali ad un
-processo. Questo è fatto specificando la cosiddetta \textsl{maschera dei
- segnali} (o \textit{signal mask}) del processo\footnote{nel caso di Linux
- essa è mantenuta dal campo \var{blocked} della \struct{task\_struct} del
- processo.} cioè l'insieme dei segnali la cui consegna è bloccata.
+
+Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi
+unix-like permettono di bloccare temporaneamente (o di eliminare
+completamente, impostando come azione \const{SIG\_IGN}) la consegna dei
+segnali ad un processo. Questo è fatto specificando la cosiddetta
+\textsl{maschera dei segnali} (o \textit{signal mask}) del
+processo\footnote{nel caso di Linux essa è mantenuta dal campo \var{blocked}
+ della \struct{task\_struct} del processo.} cioè l'insieme dei segnali la cui
+consegna è bloccata.
Abbiamo accennato in sez.~\ref{sec:proc_fork} che la maschera dei segnali
viene ereditata dal padre alla creazione di un processo figlio, e abbiamo
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{SIG\_BLOCK} & L'insieme dei segnali bloccati è l'unione fra
- quello specificato e quello corrente.\\
- \const{SIG\_UNBLOCK} & I segnali specificati in \param{set} sono rimossi
- dalla maschera dei segnali, specificare la
- cancellazione di un segnale non bloccato è legale.\\
- \const{SIG\_SETMASK} & La maschera dei segnali è impostata al valore
- specificato da \param{set}.\\
+ \constd{SIG\_BLOCK} & L'insieme dei segnali bloccati è l'unione fra
+ quello specificato e quello corrente.\\
+ \constd{SIG\_UNBLOCK} & I segnali specificati in \param{set} sono rimossi
+ dalla maschera dei segnali, specificare la
+ cancellazione di un segnale non bloccato è legale.\\
+ \constd{SIG\_SETMASK} & La maschera dei segnali è impostata al valore
+ specificato da \param{set}.\\
\hline
\end{tabular}
\caption{Valori e significato dell'argomento \param{how} della funzione
Su Linux di solito il primo valore è 33, mentre il secondo è \code{\_NSIG-1},
che di norma (vale a dire sulla piattaforma i386) è 64. Questo dà un totale di
32 segnali disponibili, contro gli almeno 8 richiesti da POSIX.1b. Si tenga
-presente però che i primi segnali \textit{real-time} disponibili vendono usati
-dalle \acr{glibc} per l'implementazione dei \textit{thread} POSIX (vedi
+presente però che i primi segnali \textit{real-time} disponibili vengono usati
+dalla \acr{glibc} per l'implementazione dei \textit{thread} POSIX (vedi
sez.~\ref{sec:thread_posix_intro}), ed il valore di \const{SIGRTMIN} viene
modificato di conseguenza.\footnote{per la precisione vengono usati i primi
tre per la vecchia implementazione dei \textit{LinuxThread} ed i primi due
vari meccanismi di notifica per restituire dati al gestore del segnale in
\var{si\_value}. Un campo di tipo \type{sigval\_t} è presente anche nella
struttura \struct{sigevent} (definita in fig.~\ref{fig:struct_sigevent}) che
-viene usata dai meccanismi di notifica come quelli per
-\itindex{POSIX~Timer~API} i timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}),
-l'I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io}) o le code di
-messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}).
+viene usata dai meccanismi di notifica come quelli per i timer POSIX (vedi
+sez.~\ref{sec:sig_timer_adv}), l'I/O asincrono (vedi
+sez.~\ref{sec:file_asyncronous_io}) o le code di messaggi POSIX (vedi
+sez.~\ref{sec:ipc_posix_mq}).
A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
inviare segnali \textit{real-time}, poiché non è in grado di fornire alcun
classica il segnale sarà generato, ma tutte le caratteristiche tipiche dei
segnali \textit{real-time} (priorità e coda) saranno perse.
-Secondo lo standard POSIX la profondità della coda è indicata dalla costante
-\const{SIGQUEUE\_MAX}, una della tante costanti di sistema definite dallo
+Per lo standard POSIX la profondità della coda è indicata dalla costante
+\constd{SIGQUEUE\_MAX}, una della tante costanti di sistema definite dallo
standard POSIX che non abbiamo riportato esplicitamente in
sez.~\ref{sec:sys_limits}. Il suo valore minimo secondo lo standard,
-\const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux la coda ha una
+\macrod{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux la coda ha una
dimensione variabile; fino alla versione 2.6.7 c'era un limite massimo globale
che poteva essere impostato come parametro del kernel in
-\sysctlfile{kernel/rtsig-max} ed il valore predefinito era pari a 1024. A
+\sysctlfiled{kernel/rtsig-max} ed il valore predefinito era pari a 1024. A
partire dal kernel 2.6.8 il valore globale è stato rimosso e sostituito dalla
risorsa \const{RLIMIT\_SIGPENDING} associata al singolo utente, che può essere
modificata con \func{setrlimit} come illustrato in
si può eliminare un segnale dalla coda senza dover essere bloccati qualora
esso non sia presente.
-\itindbeg{thread}
-
L'uso di queste funzioni è principalmente associato alla gestione dei segnali
con i \textit{thread}. In genere esse vengono chiamate dal \textit{thread}
incaricato della gestione, che al ritorno della funzione esegue il codice che
\textit{thread}, compreso quello dedicato alla gestione, che potrebbe
riceverlo fra due chiamate successive.
-\itindend{thread}
-
\subsection{La gestione avanzata delle temporizzazioni}
\label{sec:sig_timer_adv}
-% TODO: indicizzare i termini \itindex{POSIX~Timer~API} e HRT
-
Sia le funzioni per la gestione dei tempi viste in
sez.~\ref{sec:sys_cpu_times} che quelle per la gestione dei timer di
sez.~\ref{sec:sig_alarm_abort} sono state a lungo limitate dalla risoluzione
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{CLOCK\_REALTIME} & Orologio \textit{real-time} di sistema, può
+ \constd{CLOCK\_REALTIME} & Orologio \textit{real-time} di sistema, può
essere impostato solo con privilegi
amministrativi.\\
- \const{CLOCK\_MONOTONIC} & Orologio che indica un tempo monotono
+ \constd{CLOCK\_MONOTONIC} & Orologio che indica un tempo monotono
crescente (a partire da un tempo iniziale non
specificato) che non può essere modificato e
non cambia neanche in caso di reimpostazione
dell'orologio di sistema.\\
- \const{CLOCK\_PROCESS\_CPUTIME\_ID}& Contatore del tempo di CPU usato
+ \constd{CLOCK\_PROCESS\_CPUTIME\_ID}& Contatore del tempo di CPU usato
da un processo (il \textit{process time} di
sez.~\ref{sec:sys_cpu_times}, nel totale di
\textit{system time} e \textit{user time})
comprensivo di tutto il tempo di CPU usato
da eventuali \textit{thread}.\\
- \const{CLOCK\_THREAD\_CPUTIME\_ID}& Contatore del tempo di CPU
+ \constd{CLOCK\_THREAD\_CPUTIME\_ID}& Contatore del tempo di CPU
(\textit{user time} e \textit{system time})
usato da un singolo \textit{thread}.\\
\hline
- \const{CLOCK\_MONOTONIC\_RAW}&Simile al precedente, ma non subisce gli
+ \constd{CLOCK\_MONOTONIC\_RAW}&Simile al precedente, ma non subisce gli
aggiustamenti dovuti all'uso di NTP (viene
usato per fare riferimento ad una fonte
hardware). Questo orologio è specifico di
Linux, ed è disponibile a partire dal kernel
2.6.28.\\
- \const{CLOCK\_BOOTTIME} & Identico a \const{CLOCK\_MONOTONIC} ma tiene
+ \constd{CLOCK\_BOOTTIME} & Identico a \const{CLOCK\_MONOTONIC} ma tiene
conto anche del tempo durante il quale il
sistema è stato sospeso (nel caso di
sospensione in RAM o \textsl{ibernazione} su
disco. Questo orologio è specifico di Linux,
ed è disponibile a partire dal kernel
2.6.39.\\
- \const{CLOCK\_REALTIME\_ALARM}&Identico a \const{CLOCK\_REALTIME}, ma se
+ \constd{CLOCK\_REALTIME\_ALARM}&Identico a \const{CLOCK\_REALTIME}, ma se
usato per un timer il sistema sarà riattivato
anche se è in sospensione. Questo orologio è
specifico di Linux, ed è disponibile a
partire dal kernel 3.0.\\
- \const{CLOCK\_BOOTTIME\_ALARM}&Identico a \const{CLOCK\_BOOTTIME}, ma se
+ \constd{CLOCK\_BOOTTIME\_ALARM}&Identico a \const{CLOCK\_BOOTTIME}, ma se
usato per un timer il sistema sarà riattivato
anche se è in sospensione. Questo orologio è
specifico di Linux, ed è disponibile a
\end{table}
+% TODO: dal 4.17 CLOCK_MONOTONIC e CLOCK_BOOTTIME sono identici vedi
+% https://lwn.net/Articles/751651/ e
+% 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
-Per poter utilizzare queste funzionalità le \acr{glibc} richiedono che la
+% 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
programmi che le usano devono essere collegati con la libreria delle
estensioni \textit{real-time} usando esplicitamente l'opzione \texttt{-lrt}.
Si tenga presente inoltre che la disponibilità di queste funzionalità avanzate
-può essere controllato dalla definizione della macro \macro{\_POSIX\_TIMERS}
+può essere controllato dalla definizione della macro \macrod{\_POSIX\_TIMERS}
ad un valore maggiore di 0, e che le ulteriori macro
-\macro{\_POSIX\_MONOTONIC\_CLOCK}, \macro{\_POSIX\_CPUTIME} e
-\macro{\_POSIX\_THREAD\_CPUTIME} indicano la presenza dei rispettivi orologi
+\macrod{\_POSIX\_MONOTONIC\_CLOCK}, \macrod{\_POSIX\_CPUTIME} e
+\macrod{\_POSIX\_THREAD\_CPUTIME} indicano la presenza dei rispettivi orologi
di tipo \const{CLOCK\_MONOTONIC}, \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
-\const{CLOCK\_PROCESS\_CPUTIME\_ID}; tutte queste macro sono definite in
+\const{CLOCK\_THREAD\_CPUTIME\_ID}; tutte queste macro sono definite in
\headfile{unistd.h}, che pertanto deve essere incluso per poterle
controllarle. Infine se il kernel ha il supporto per gli \textit{high
resolution timer} un elenco degli orologi e dei timer può essere ottenuto
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{SIGEV\_NONE} & Non viene inviata nessuna notifica.\\
- \const{SIGEV\_SIGNAL} & La notifica viene effettuata inviando al processo
+ \constd{SIGEV\_NONE} & Non viene inviata nessuna notifica.\\
+ \constd{SIGEV\_SIGNAL} & La notifica viene effettuata inviando al processo
chiamante il segnale specificato dal campo
\var{sigev\_signo}; se il gestore di questo
segnale è stato installato con
\dirct{union} \texttt{sigval}, la cui definizione
è in fig.~\ref{fig:sig_sigval}) come valore del
campo \var{si\_value} di \struct{siginfo\_t}.\\
- \const{SIGEV\_THREAD} & La notifica viene effettuata creando un nuovo
+ \constd{SIGEV\_THREAD} & La notifica viene effettuata creando un nuovo
\textit{thread} che esegue la funzione di
notifica specificata da
\var{sigev\_notify\_function} con argomento
\val{NULL}, il \textit{thread} viene creato con
gli attributi specificati da
\var{sigev\_notify\_attribute}.\footnotemark\\
- \const{SIGEV\_THREAD\_ID}& Invia la notifica come segnale (con le stesse
+ \constd{SIGEV\_THREAD\_ID}& Invia la notifica come segnale (con le stesse
modalità di \const{SIGEV\_SIGNAL}) che però viene
recapitato al \textit{thread} indicato dal campo
\var{sigev\_notify\_thread\_id}. Questa modalità
valore di \param{flags} è nullo, questo valore viene considerato come un
intervallo relativo al tempo corrente, il primo allarme scatterà cioè dopo il
numero di secondi e nanosecondi indicati da questo campo. Se invece si usa
-per \param{flags} il valore \const{TIMER\_ABSTIME}, che al momento è l'unico
+per \param{flags} il valore \constd{TIMER\_ABSTIME}, che al momento è l'unico
valore valido per \param{flags}, allora \var{it\_value} viene considerato come
un valore assoluto rispetto al valore usato dall'orologio a cui è associato il
timer.
Infine, quando un timer non viene più utilizzato, lo si può cancellare,
rimuovendolo dal sistema e recuperando le relative risorse, effettuando in
-sostanza l'operazione inversa rispetto a \funcd{timer\_create}. Per questo
+sostanza l'operazione inversa rispetto a \func{timer\_create}. Per questo
compito lo standard prevede una apposita funzione di sistema,
\funcd{timer\_delete}, il cui prototipo è:
funzione ritorna immediatamente senza nessuna sospensione. In caso di
interruzione da parte di un segnale il tempo rimanente viene restituito
in \param{remain} soltanto se questo non è un puntatore \val{NULL} e non si è
-specificato \const{TIMER\_ABSTIME} per \param{flags} .
+specificato \const{TIMER\_ABSTIME} per \param{flags}.
-% TODO manca clock_nanosleep, referenziata in sez.~\ref{sec:sig_gen_beha}
\itindend{POSIX~Timer~API}
segnali non descritte finora, relative agli aspetti meno utilizzati e più
``\textsl{esoterici}'' della interfaccia.
+% TODO: trattare (qui?) pidfd_send_signal() introdotta con il kernel 5.1 vedi
+% https://lwn.net/Articles/784831/ e https://lwn.net/Articles/773459/
+
La prima di queste funzioni è la funzione di sistema \funcd{sigpending},
anch'essa introdotta dallo standard POSIX.1, il suo prototipo è:
escluderne l'avvenuto invio al momento della chiamata non significa nulla
rispetto a quanto potrebbe essere in un qualunque momento successivo.
-\itindbeg{stack}
-
Una delle caratteristiche di BSD, disponibile anche in Linux, è la possibilità
di usare uno \textit{stack} alternativo per i segnali; è cioè possibile fare
usare al sistema un altro \textit{stack} (invece di quello relativo al
In genere il primo passo viene effettuato allocando un'opportuna area di
memoria con \code{malloc}; in \headfile{signal.h} sono definite due costanti,
-\const{SIGSTKSZ} e \const{MINSIGSTKSZ}, che possono essere utilizzate per
+\constd{SIGSTKSZ} e \constd{MINSIGSTKSZ}, che possono essere utilizzate per
allocare una quantità di spazio opportuna, in modo da evitare overflow. La
prima delle due è la dimensione canonica per uno \textit{stack} di segnali e
di norma è sufficiente per tutti gli usi normali.
nuovo \textit{stack} occorre inizializzare \var{ss\_sp} e \var{ss\_size}
rispettivamente al puntatore e alla dimensione della memoria allocata, mentre
\var{ss\_flags} deve essere nullo. Se invece si vuole disabilitare uno
-\textit{stack} occorre indicare \const{SS\_DISABLE} come valore di
+\textit{stack} occorre indicare \constd{SS\_DISABLE} come valore di
\var{ss\_flags} e gli altri valori saranno ignorati.
Se \param{oss} non è nullo verrà restituito dalla funzione indirizzo e
dimensione dello \textit{stack} corrente nei relativi campi, mentre
-\var{ss\_flags} potrà assumere il valore \const{SS\_ONSTACK} se il processo è
+\var{ss\_flags} potrà assumere il valore \constd{SS\_ONSTACK} se il processo è
in esecuzione sullo \textit{stack} alternativo (nel qual caso non è possibile
cambiarlo) e \const{SS\_DISABLE} se questo non è abilitato.
conseguenze imprevedibili). Si ricordi infine che una chiamata ad una
funzione della famiglia \func{exec} cancella ogni \textit{stack} alternativo.
-\itindend{stack}
-
Abbiamo visto in fig.~\ref{fig:sig_sleep_incomplete} come si possa usare
\func{longjmp} per uscire da un gestore rientrando direttamente nel corpo
del programma, sappiamo però che nell'esecuzione di un gestore il segnale
normale ritorno, mentre quella usata da System V no.
Lo standard POSIX.1 non specifica questo comportamento per \func{setjmp} e
-\func{longjmp}, ed il comportamento delle \acr{glibc} dipende da quale delle
+\func{longjmp}, ed il comportamento della \acr{glibc} dipende da quale delle
caratteristiche si sono abilitate con le macro viste in
sez.~\ref{sec:intro_gcc_glibc_std}.
projects / gapil.git / blobdiff