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.
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
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
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
\subsection{Le funzioni di allarme ed i \textit{timer}}
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*}
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:
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
% 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
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}.