%% signal.tex
%%
-%% Copyright (C) 2000-2015 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2018 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
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.
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},
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
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}.}
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}
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
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
+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,
-\constd{\_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
\sysctlfiled{kernel/rtsig-max} ed il valore predefinito era pari a 1024. 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
+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
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 è:
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