%% signal.tex
%%
-%% Copyright (C) 2000-2019 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2024 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",
\begin{table}[!htb]
\footnotesize
\centering
- \begin{tabular}[c]{|l|p{10cm}|}
+ \begin{tabular}[c]{|l|p{8cm}|}
\hline
\textbf{Valore} & \textbf{Significato} \\
\hline
vengono riutilizzati e ciascuno di essi avrà un significato diverso a seconda
del segnale a cui è associato.
-L'elenco dettagliato dei nomi di queste costanti è riportato nelle diverse
-sezioni di tab.~\ref{tab:sig_si_code_special} che sono state ordinate nella
-sequenza in cui si sono appena citati i rispettivi segnali, il prefisso del
-nome indica comunque in maniera diretta il segnale a cui le costanti fanno
-riferimento.
-
\begin{table}[!htb]
\footnotesize
\centering
- \begin{tabular}[c]{|l|p{10cm}|}
+ \begin{tabular}[c]{|l|p{8cm}|}
\hline
\textbf{Valore} & \textbf{Significato} \\
\hline
\label{tab:sig_si_code_special}
\end{table}
+L'elenco dettagliato dei nomi di queste costanti è riportato nelle diverse
+sezioni di tab.~\ref{tab:sig_si_code_special} che sono state ordinate nella
+sequenza in cui si sono appena citati i rispettivi segnali, il prefisso del
+nome indica comunque in maniera diretta il segnale a cui le costanti fanno
+riferimento.
+
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
\func{signal} occorre molta attenzione, in quanto le due funzioni possono
interagire in maniera anomala. Infatti l'azione specificata con
\struct{sigaction} contiene un maggior numero di informazioni rispetto al
-semplice indirizzo del gestore restituito da \func{signal}. Per questo motivo
-se si usa quest'ultima per installare un gestore sostituendone uno
+semplice indirizzo del gestore restituito da \func{signal}, e questo comporta
+che se si usa quest'ultima per installare un gestore sostituendone uno
precedentemente installato con \func{sigaction}, non sarà possibile effettuare
un ripristino corretto dello stesso.
-Per questo è sempre opportuno usare \func{sigaction}, che è in grado di
+Per questo motivo è opportuno usare sempre \func{sigaction} che è in grado di
ripristinare correttamente un gestore precedente, anche se questo è stato
installato con \func{signal}. In generale poi non è il caso di usare il valore
di ritorno di \func{signal} come campo \var{sa\_handler}, o viceversa, dato
-che in certi sistemi questi possono essere diversi. In definitiva dunque, a
-meno che non si sia vincolati all'aderenza stretta allo standard ISO C, è
-sempre il caso di evitare l'uso di \func{signal} a favore di \func{sigaction}.
+che in certi sistemi questi valori possono essere diversi. In definitiva
+dunque, a meno che non si sia vincolati all'aderenza stretta allo standard ISO
+C, è sempre il caso di evitare l'uso di \func{signal} a favore di
+\func{sigaction}.
\begin{figure}[!htbp]
\footnotesize \centering
\label{fig:sig_Signal_code}
\end{figure}
-Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
-che abbia le stesse caratteristiche di \func{signal}, a definire attraverso
-\func{sigaction} una funzione equivalente \func{Signal}, il cui codice è
-riportato in fig.~\ref{fig:sig_Signal_code} (il codice completo si trova nel
-file \file{SigHand.c} nei sorgenti allegati). Anche in questo caso, per
-semplificare la definizione si è poi definito un apposito tipo
-\texttt{SigFunc} per esprimere in modo più comprensibile la forma di un
-gestore di segnale.
+Come primo esmpio si è allora provveduto, per mantenere un'interfaccia
+semplificata che abbia le stesse caratteristiche di \func{signal}, a definire
+attraverso \func{sigaction} una funzione equivalente, \func{Signal}, il cui
+codice è riportato in fig.~\ref{fig:sig_Signal_code} (il codice completo si
+trova nel file \file{SigHand.c} nei sorgenti allegati). Anche in questo caso,
+per semplificare la definizione si è poi definito un apposito tipo
+\texttt{SigHandler} per esprimere in modo più semplice la forma di un gestore
+di segnale.
Si noti come, essendo la funzione estremamente semplice, essa è definita come
\dirct{inline}. Questa direttiva viene usata per dire al compilatore di
di problemi di sintassi nel passaggio degli argomenti (si veda ad esempio
\cite{PratC}) che in questo modo possono essere evitati.
+La funzione \func{Signal} appena illustrata continua però ad utilizzare la
+forma tradizionale del gestore di segnali, mentre abbiamo visto come
+\func{sigaction} preveda la possibilità di indicare, attivando il flag
+\const{SA\_SIGINFO}, un gestore nella forma avanzata \param{sa\_sigaction}, in
+grado di ricevere molte più informazioni, che prevede l'utilizzo di tre
+argomenti. Di nuovo facciamo un esempio di come usare \func{sigaction} in
+questo caso, partendo col definire un apposito tipo, \texttt{SigAction}, per
+semplificare l'indicazione del nuovo tipo di gestore:
+\includecodesnip{listati/SigAction.c}
+
+Un gestore di segnali definito nella forma \val{sa\_sigaction} infatti, oltre
+al numero di segnale ricevuto come primo argomento, otterrà dal kernel un
+puntatore ad una struttura \struct{siginfo\_t} con le relative informazioni
+attienti l'origine del segnale nel secondo argomento, ed infine un puntatore a
+delle informazioni di contesto ad uso delle librerie del C nel terzo
+argomento, che non vengono mai utilizzate nel gestore, attenendo al
+funzionamento a basso livello della gestione dei segnali.\footnote{il kernel
+ tutte le volte che c'è un segnale pendente gestisce l'esecuzione del
+ relativo gestore caricando nello stack i dati del contesto di esecuzione del
+ processo e facendo sì che al ritorno in \textit{user-space} sia eseguito il
+ gestore, una volta che questo ritorna il controllo viene passato a dello
+ specifico codice in \textit{user-space}, detto \itindex{signal~trampoline}
+ \textit{signal trampoline}, che con la funzione di sistema \funcm{sigreturn}
+ usa le informazioni di contesto disponibili in questo argomento per far
+ riprendere l'esecuzione del processo al punto in cui si era stata interrotta
+ dal segnale; tutto ciò è gestito dal kernel e dalle librerie del C e non
+ interessa la programmazione ordinaria.}
+
+Si è riportato in fig.~\ref{fig:sig_Action_code} un equivalente della
+precedente \func{Signal} che però installa un gestore di segnali di tipo
+\param{sa\_sigaction}. Si noti come la funzione, una volta definito come sopra
+il tipo \texttt{SigAction} per il gestore di segnali, sia praticamente
+identica all'altra.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/Action.c}
+ \end{minipage}
+ \normalsize
+ \caption{La funzione \func{Action}, analoga alla precedente \func{Signal}
+ per l'uso dei gestori di segnali avanzati con \func{sigaction}.}
+ \label{fig:sig_Action_code}
+\end{figure}
+
+Quello che cambia in questo caso è occorre indicare (\texttt{\small 4}) nel
+campo \var{sa\_flags} della struttura \struct{sigaction} il valore
+\const{SA\_SIGINFO}, perché poi si passerà (\texttt{\small 5}) l'indirizzo il
+del gestore nel campo \var{sa\_sigaction} invece che in \var{sa\_handler} come
+nel caso precedente.
+
+Inoltre in questo caso, ritornando la funzione l'indirizzo del gestore che è
+nella nuova forma, non si può terminare in caso di errore riportanto il valore
+\const{SIG\_ERR} (che è di tipo \type{sighandler\_t} e fa riferimento ad un
+gestore ordinario) come in precedenza. Per questo motivo si è scelto di
+ritornare come indicazione di errore il valore \val{NULL}, ma in questo caso
+si deve tenere presente che questo valore non è più distinto da quello che si
+utilizza per indicare la eventuale reimpostazione del gestore di default (come
+era \const{SIG\_ERR} rispetto a \const{SIG\_DFL}).
+
+Per questo motivo questa funzione viene illustrata solo a scopo di primo
+esempio, vedremo più avanti, in sez.~\ref{sec:sig_real_time}, nel contesto
+dell'uso dei segnali \textit{real-time} per i quali è nata questa nuova
+interfaccia, un esempio più completo dell'uso di \func{sigaction} con un
+gestore in questa nuova forma, e di come utilizzare le informazioni ottenute
+nella struttura \struct{siginfo\_t}.
\subsection{La gestione della \textsl{maschera dei segnali} o
citato un controllo ed una assegnazione) o comunque eseguire una serie di
istruzioni, l'atomicità non è più possibile.
-In questo caso, se si vuole essere sicuri di non poter essere interrotti da
-uno o più segnali durante l'esecuzione di una sezione di codice, li si possono
-bloccare esplicitamente modificando la maschera dei segnali del processo
-usando la funzione di sistema \funcd{sigprocmask},\footnote{in realtà quello
- che viene usato normalmente è il \textit{wrapper} omonimo delle \acr{glibc}
- dato che con l'introduzione dei segnali \textit{real time} nel kernel 2.2 le
- dimensioni del tipo \type{sigset\_t} sono cambiate e la \textit{system call}
- sottostante è diventata \funcm{rt\_sigprocmask} che richiede un quarto
- argomento di tipo \ctyp{size\_t} per indicare questa dimensione; il
- \textit{wrapper} maschera questi dettagli ed inoltre ignora in maniera
- silente i tentativi di bloccare i segnali \textit{real time} impiegati per
- la gestione dei \textit{thread} dalla \textit{Native Thread Posix Library}
- (vedi sez.~\ref{sec:linux_ntpl}).} il cui prototipo è:
+In questo caso, quando si vuole essere sicuri di non essere interrotti da uno
+o più segnali durante l'esecuzione di una sezione di codice, diventa
+necessario bloccarli esplicitamente. Questo si fa modificando la maschera dei
+segnali del processo e per fare questa operazione con lo standard POSIX-1.2001
+è stata introdotta una apposita funzione di sistema,
+\funcd{sigprocmask},\footnote{in realtà quello che viene usato normalmente è
+ il \textit{wrapper} omonimo delle \acr{glibc} dato che con l'introduzione
+ dei segnali \textit{real time} nel kernel 2.2 le dimensioni del tipo
+ \type{sigset\_t} sono cambiate e la \textit{system call} sottostante è
+ diventata \funcm{rt\_sigprocmask} che richiede un quarto argomento di tipo
+ \ctyp{size\_t} per indicare questa dimensione; la vecchia funzione di
+ sistema continua ad esistere ma è deprecata, il \textit{wrapper} maschera
+ questi dettagli ed inoltre ignora in maniera silente i tentativi di bloccare
+ i segnali \textit{real time} impiegati per la gestione dei \textit{thread}
+ dalla \textit{Native Thread Posix Library} (vedi
+ sez.~\ref{sec:linux_ntpl}).} il cui prototipo è:
\begin{funcproto}{
\fhead{signal.h}
La funzione usa l'insieme di segnali posto all'indirizzo passato
nell'argomento \param{set} per modificare la maschera dei segnali del processo
-corrente. La modifica viene effettuata a seconda del valore
-dell'argomento \param{how}, secondo le modalità specificate in
-tab.~\ref{tab:sig_procmask_how}. Qualora si specifichi un valore non nullo
-per \param{oldset} la maschera dei segnali corrente viene salvata a
-quell'indirizzo. Se è nullo \param{set} non viene eseguito nessun cambiamento
-e si può usare la funzione per leggere la maschera corrente in \param{oldset}.
+corrente. La modifica viene effettuata a seconda del valore dell'argomento
+\param{how}, secondo le modalità specificate in
+tab.~\ref{tab:sig_procmask_how}. Qualora si specifichi un indirizzo non nullo
+per il puntatore \param{oldset} la maschera dei segnali corrente viene salvata
+a quell'indirizzo. Se invece è nullo il puntatore \param{set} non viene
+eseguito nessun cambiamento e si può usare la funzione per leggere la maschera
+corrente in \param{oldset}.
\begin{table}[htb]
\footnotesize
La funzione consente di proteggere delle sezioni di codice bloccando l'insieme
di segnali voluto per poi riabilitarli alla fine della sezione critica e
risolvere problemi come quelli mostrati in fig.~\ref{fig:sig_event_wrong},
-proteggendo la sezione fra il controllo del flag e la sua cancellazione. La
-funzione può essere usata anche all'interno di un gestore, ad esempio per
+proteggendo la sezione fra il controllo del flag e la sua cancellazione.
+
+La funzione può essere usata anche all'interno di un gestore, ad esempio per
riabilitare la consegna del segnale che l'ha invocato, in questo caso però
occorre ricordare che qualunque modifica alla maschera dei segnali viene
perduta al ritorno dallo stesso.
nell'esempio di fig.~\ref{fig:sig_sleep_incomplete}, e cioè la possibilità che
il processo riceva il segnale che si intende usare per uscire dallo stato di
attesa invocato con \func{pause} immediatamente prima dell'esecuzione di
-quest'ultima. Per poter effettuare atomicamente la modifica della maschera dei
-segnali (di solito attivandone uno specifico) insieme alla sospensione del
-processo lo standard POSIX ha previsto la funzione di sistema
-\funcd{sigsuspend}, il cui prototipo è:
+quest'ultima.
+
+Per poter effettuare atomicamente la modifica della maschera dei segnali (di
+solito attivandone uno specifico) insieme alla sospensione del processo lo
+standard POSIX ha previsto la funzione di sistema \funcd{sigsuspend}, il cui
+prototipo è:
\begin{funcproto}{
\fhead{signal.h}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
- \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
+ \item[\errcode{EFAULT}] l'indirizzo di \param{mask} non è valido.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\end{errlist}
}
\end{funcproto}
+La funzione imposta la maschera dei segnali indicata da \param{mask} e pone in
+attesa il processo. Ritorna solo con la ricezione di un segnale, con un errore
+di \errval{EINTR}, a meno che il segnale non termini il processo.
+
Come esempio dell'uso di queste funzioni proviamo a riscrivere un'altra volta
l'esempio di implementazione di \code{sleep}. Abbiamo accennato in
sez.~\ref{sec:sig_sigaction} come con \func{sigaction} sia possibile bloccare
in forma estesa.
In particolare i campi di \struct{siginfo\_t} utilizzati dai segnali
-\textit{real-time} sono \var{si\_pid} e \var{si\_uid} in cui vengono
-memorizzati rispettivamente il \ids{PID} e l'\ids{UID} effettivo del processo
-che ha inviato il segnale, ed il campo \var{si\_value} che viene usato
-appositamente per poter restituire dei dati al gestore.
+\textit{real-time} sono \var{si\_pid} e \var{si\_uid} in cui vengono riportati
+rispettivamente il \ids{PID} e l'\ids{UID} effettivo del processo che ha
+inviato il segnale, e lo specifico campo \var{si\_value}. Questo campo viene
+indicato in fig.~\ref{fig:sig_siginfo_t} come di tipo \type{sigval\_t}; se ne
+è riportata la definizione in fig.~\ref{fig:sig_sigval}.
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:sig_sigval}
\end{figure}
-Detto campo, la cui definizione è riportata in fig.~\ref{fig:sig_sigval},
-viene indicato con il tipo di dato \type{sigval\_t}, che è una \dirct{union}
-di tipo \struct{sigval} in cui può essere memorizzato o un valore numerico, se
-usata nella forma \var{sival\_int}, o un puntatore, se usata nella forma
-\var{sival\_ptr}.
-
-L'unione viene usata dai segnali \textit{real-time} e da 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 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
-valore per il campo \var{si\_value} restituito nella struttura
-\struct{siginfo\_t} prevista da un gestore in forma estesa. Per questo motivo
-lo standard ha previsto una nuova funzione, \funcd{sigqueue}, il cui prototipo
-è:
+Si tratta quindi di una unione \struct{sigval} con due possibili campi
+alternativi in cui può essere memorizzato o un valore numerico, se usata con
+\var{sival\_int}, o un puntatore, se usata con \var{sival\_ptr}. L'unione
+viene usata dai segnali \textit{real-time}, ma anche da vari altri meccanismi
+di notifica, per inviare eventuali informazioni aggiuntive al gestore del
+segnale in \var{si\_value}. Ad esempio un campo di tipo \type{sigval\_t} è
+presente anche nella struttura \struct{sigevent} (definita in
+fig.~\ref{fig:struct_sigevent}) che viene usata da vari meccanismi di notifica
+come quelli per i timer POSIX (che vedremo in sez.~\ref{sec:sig_timer_adv}),
+quello dell'I/O asincrono (che vedremo in sez.~\ref{sec:file_asyncronous_io})
+o dalle code di messaggi POSIX (che vedremo in sez.~\ref{sec:ipc_posix_mq}).
+
+A causa di questa loro caratteristica, la funzione \func{kill}, pure essendo
+utilizzabile, non è adatta ad inviare segnali \textit{real-time}, perché non è
+in grado di impostare alcun valore per il campo \var{si\_value}. Per questo
+motivo lo standard POSIX ha previsto una nuova funzione, \funcd{sigqueue}, il
+cui prototipo è:
\begin{funcproto}{
\fhead{signal.h}
}
\end{funcproto}
-
La funzione invia il segnale indicato dall'argomento \param{signo} al processo
indicato dall'argomento \param{pid}. Per il resto il comportamento della
funzione è analogo a quello di \func{kill}, ed i privilegi occorrenti ad
\fdecl{int sigwait(const sigset\_t *set, int *sig)}
\fdesc{Attende la ricezione di un segnale.}
}
-{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} assumerà uno dei valori:
+{La funzione ritorna $0$ in caso di successo ed un valore positivo in caso di
+ errore con valore secondo la lista seguente:
\begin{errlist}
- \item[\errcode{EINTR}] la funzione è stata interrotta.
- \item[\errcode{EINVAL}] si è specificato un valore non valido per
+ \item[\errcode{EINVAL}] \param{set} contiene un numero di segnale non valido
\end{errlist}
ed inoltre \errval{EFAULT} nel suo significato generico.}
\end{funcproto}
\textit{thread}, compreso quello dedicato alla gestione, che potrebbe
riceverlo fra due chiamate successive.
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/rtsigvalsend.c}
+ \end{minipage}
+ \normalsize
+ \caption{Corpo principale di un programma di invio di segnali
+ \textit{real-time}.}
+ \label{fig:sig_rtsival_main}
+\end{figure}
+
+Come esempio elementare dell'uso dei segnali \textit{real-time}, e della
+possibilità di inviare informazioni al gestore degli stessi con
+\func{sigqueue}, si è riportato in fig.~\ref{fig:sig_rtsival_main} il corpo
+principale di un programma elementare che legge dal terminale un valore
+numerico, ed utilizza un segnale \textit{real-time} per inviarlo al gestore
+dello stesso. Nel codice sono stati trascurati i controlli dei valori di
+ritorno delle varie funzioni per mantenere la brevità dell'esempio.
+
+Dopo aver definito (\texttt{\small 5}) una variabile \var{value} di tipo
+\type{sigval\_t} per poter inviare i dati, e dopo aver opportunamente scelto
+(\texttt{\small 6}) per \var{signo} un segnale \textit{real-time}, la parte
+iniziale del programma (\texttt{\small 8--11}) installa il relativo gestore
+(la cui definizione è riportata in fig.~\ref{fig:sig_rtsival_handl}). Dopo di
+che il programma si pone in un ciclo infinito (\texttt{\small 14--27}) in cui
+prima (\texttt{\small 15--20}) legge in buffer dallo \textit{standard input}
+una stringa immessa dall'utente, terminandola opportunamente (\texttt{\small
+ 20}), e poi tenta di convertire la stessa (\texttt{\small 21}) in un numero
+con \func{strtol}, assegnando il risultato a \texttt{value.sival\_int}, se la
+conversione ha successo e \texttt{value.sival\_int} è positivo) invia a se
+stesso (\texttt{\small 23}) il segnale \textit{real-time}, altrimenti stampa
+un avviso (\texttt{\small 24}).
+
+Alla ricezione del segnale il gestore si limita a stampare alcune delle
+informazioni ricevute nella struttura \struct{sigval\_t}, ed in particolare
+(\texttt{\small 5}) stampa tramite il valore del campo \var{si\_value} il
+numero che gli è stato inviato da \func{sigqueue}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/rtsigvalsend_handl.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice del gestore usato dal programma di
+ fig.~\ref{fig:sig_rtsival_main}.}
+ \label{fig:sig_rtsival_handl}
+\end{figure}
+
\subsection{La gestione avanzata delle temporizzazioni}
\label{sec:sig_timer_adv}
altre funzioni per il supporto delle estensioni \textit{real-time} con il
rilascio del kernel 2.6, ma la risoluzione effettiva era nominale.
-A tutte le implementazioni che si rifanno a queste estensioni è richiesto di
-disporre di una versione \textit{real-time} almeno per l'orologio generale di
-sistema, quello che mantiene il \textit{calendar time} (vedi
-sez.~\ref{sec:sys_time_base}), che in questa forma deve indicare il numero di
-secondi e nanosecondi passati a partire dal primo gennaio 1970 (\textit{The
- Epoch}). Si ricordi infatti che l'orologio ordinario usato dal
-\textit{calendar time} riporta solo un numero di secondi, e che la risoluzione
-effettiva normalmente non raggiunge il nanosecondo (a meno di hardware
-specializzato). Oltre all'orologio generale di sistema possono essere
-presenti altri tipi di orologi \textit{real-time}, ciascuno dei quali viene
-identificato da un opportuno valore di una variabile di tipo
-\type{clockid\_t}; un elenco di quelli disponibili su Linux è riportato in
-tab.~\ref{tab:sig_timer_clockid_types}.
-
\begin{table}[htb]
\footnotesize
\centering
\label{tab:sig_timer_clockid_types}
\end{table}
+A tutte le implementazioni che si rifanno a queste estensioni è richiesto di
+disporre di una versione \textit{real-time} almeno per l'orologio generale di
+sistema, quello che mantiene il \textit{calendar time} (vedi
+sez.~\ref{sec:sys_time_base}), che in questa forma deve indicare il numero di
+secondi e nanosecondi passati a partire dal primo gennaio 1970 (\textit{The
+ Epoch}). Si ricordi infatti che l'orologio ordinario usato dal
+\textit{calendar time} riporta solo un numero di secondi, e che la risoluzione
+effettiva normalmente non raggiunge il nanosecondo (a meno di hardware
+specializzato). Oltre all'orologio generale di sistema possono essere
+presenti altri tipi di orologi \textit{real-time}, ciascuno dei quali viene
+identificato da un opportuno valore di una variabile di tipo
+\type{clockid\_t}; un elenco di quelli disponibili su Linux è riportato in
+tab.~\ref{tab:sig_timer_clockid_types}.
% TODO: dal 4.17 CLOCK_MONOTONIC e CLOCK_BOOTTIME sono identici vedi
% https://lwn.net/Articles/751651/ e
per \func{clock\_gettime} verrà restituito al suo interno il valore corrente
dello stesso.
-Si tenga presente inoltre che per eseguire un cambiamento sull'orologio
-generale di sistema \const{CLOCK\_REALTIME} occorrono i privilegi
-amministrativi;\footnote{ed in particolare la \textit{capability}
- \const{CAP\_SYS\_TIME}.} inoltre ogni cambiamento ad esso apportato non avrà
-nessun effetto sulle temporizzazioni effettuate in forma relativa, come quelle
-impostate sulle quantità di \textit{process time} o per un intervallo di tempo
-da trascorrere, ma solo su quelle che hanno richiesto una temporizzazione ad
-un istante preciso (in termini di \textit{calendar time}). Si tenga inoltre
-presente che nel caso di Linux \const{CLOCK\_REALTIME} è l'unico orologio per
-cui si può effettuare una modifica, infatti nonostante lo standard preveda la
-possibilità di modifiche anche per \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
+Per eseguire un cambiamento sull'orologio generale di sistema
+\const{CLOCK\_REALTIME} occorrono i privilegi amministrativi;\footnote{ed in
+ particolare la \textit{capability} \const{CAP\_SYS\_TIME}.} e che ogni
+cambiamento ad esso apportato non avrà nessun effetto sulle temporizzazioni
+effettuate in forma relativa, come quelle impostate sulle quantità di
+\textit{process time} o per un intervallo di tempo da trascorrere, ma solo su
+quelle che hanno richiesto una temporizzazione ad un istante preciso (in
+termini di \textit{calendar time}). Si tenga inoltre presente che nel caso di
+Linux \const{CLOCK\_REALTIME} è l'unico orologio per cui si può effettuare una
+modifica, infatti nonostante lo standard preveda la possibilità di modifiche
+anche per \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
\const{CLOCK\_THREAD\_CPUTIME\_ID}, il kernel non le consente.
Oltre alle due funzioni precedenti, lo standard POSIX prevede una terza
multiplo intero di questa risoluzione, sarà troncato in maniera automatica.
Gli orologi elencati nella seconda sezione di
-tab.~\ref{tab:sig_timer_clockid_types} sono delle estensioni specifiche di
-Linux, create per rispondere ad alcune esigenze specifiche, come quella di
-tener conto di eventuali periodi di sospensione del sistema, e presenti solo
-nelle versioni più recenti del kernel. In particolare gli ultimi due,
-contraddistinti dal suffisso \texttt{\_ALARM}, hanno un impiego particolare,
-derivato dalle esigenze emerse con Android per l'uso di Linux sui cellulari,
-che consente di creare timer che possono scattare, riattivando il sistema,
-anche quando questo è in sospensione. Per il loro utilizzo è prevista la
-necessità di una capacità specifica, \const{CAP\_WAKE\_ALARM} (vedi
-sez.~\ref{sec:proc_capabilities}).
+tab.~\ref{tab:sig_timer_clockid_types} sono estensioni specifiche di Linux
+presenti solo nelle versioni più recenti del kernel, create per rispondere ad
+alcune esigenze specifiche come quella di tener conto di eventuali periodi di
+sospensione del sistema. In particolare gli ultimi due, contraddistinti dal
+suffisso \texttt{\_ALARM}, hanno un impiego particolare derivato dalle
+esigenze emerse con Android per l'uso di Linux sui cellulari, che consente di
+creare timer che possono scattare, riattivando il sistema, anche quando questo
+è in sospensione. Per il loro utilizzo è prevista la necessità di una capacità
+specifica, \const{CAP\_WAKE\_ALARM} (vedi sez.~\ref{sec:proc_capabilities}).
Si tenga presente inoltre che con l'introduzione degli \textit{high resolution
timer} i due orologi \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
La funzione permette di ricavare quali sono i segnali pendenti per il processo
in corso, cioè i segnali che sono stati inviati dal kernel ma non sono stati
ancora ricevuti dal processo in quanto bloccati. Non esiste una funzione
-equivalente nella vecchia interfaccia, ma essa è tutto sommato poco utile,
-dato che essa può solo assicurare che un segnale è stato inviato, dato che
-escluderne l'avvenuto invio al momento della chiamata non significa nulla
-rispetto a quanto potrebbe essere in un qualunque momento successivo.
+equivalente nella vecchia interfaccia, ma essa, potendo solo assicurare che un
+segnale è stato inviato, è tutto sommato poco utile dato che escluderne
+l'avvenuto invio al momento della chiamata non significa nulla rispetto a
+quanto potrebbe accadere in un qualunque momento successivo.
Una delle caratteristiche di BSD, disponibile anche in Linux, è la possibilità
di usare uno \textit{stack} alternativo per i segnali; è cioè possibile fare
% LocalWords: ILL ILLOPC ILLOPN ILLADR ILLTRP PRVOPC PRVREG COPROC BADSTK FPE
% LocalWords: INTDIV INTOVF FLTDIV FLTOVF FLTUND underflow FLTRES FLTINV SEGV
% LocalWords: FLTSUB MAPERR ACCERR ADRALN ADRERR OBJERR BRKPT CLD EXITED MSG
-% LocalWords: KILLED DUMPED TRAPPED STOPPED CONTINUED PRI HUP SigFunc jiffies
+% LocalWords: KILLED DUMPED TRAPPED STOPPED CONTINUED PRI HUP SigHandler
% LocalWords: SEC unsafe sockatmark execl execv faccessat fchmodat fchownat
% LocalWords: fexecve fstatat futimens linkat mkdirat mkfifoat mknod mknodat
% LocalWords: openat readlinkat renameat symlinkat unlinkat utimensat utimes
% LocalWords: epoch multiplexing overrun res lpthread sec nsec curr one shot
% LocalWords: delete stopped gdb alpha mips emulation locking ppoll epoll PGID
% LocalWords: pwait msgrcv msgsnd semop semtimedop runnable sigisemptyset HRT
-% LocalWords: sigorset sigandset BOOTTIME Android request remain cap dell'
+% LocalWords: sigorset sigandset BOOTTIME Android request remain cap jiffies
%%% Local Variables:
projects / gapil.git / blobdiff