cui campi indicano i diversi tipi di valori che possono essere salvati, in
maniera alternativa, all'interno della stessa.}
-Installando un gestore di tipo \var{sa\_sigaction} diventa possibile
+Installando un gestore di tipo \var{sa\_sigaction} diventa possibile
accedere alle informazioni restituite attraverso il puntatore a questa
struttura. Tutti i segnali impostano i campi \var{si\_signo}, che riporta il
numero del segnale ricevuto, \var{si\_errno}, che riporta, quando diverso da
\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}
Nella successiva revisione di POSIX.1-2013 sono poi state aggiunte le
ulteriori funzioni \func{fchdir}, \func{pthread\_kill}, \func{pthread\_self},
\func{pthread\_sigmask}. L'ultima revisione dello standard alla data della
-scrittura di questa sezione è la POSIX.1-2016,\footnote{un elenco è comunque
- ottenibile dalla documentazione di sistema, accessibile con \texttt{man
- signal-safety}, da cui si sono estratti questi elenchi.} che ha aggiunto
-alle \textit{signal safe function} le ulteriori funzioni di
-fig.~\ref{fig:sig_safe_functions_posix_2016}.
+scrittura di questa sezione è la POSIX.1-2016,\footnote{una lista più
+ aggiornata può comunque essere ottenuto dalla documentazione di sistema,
+ accessibile con \texttt{man signal-safety}, da cui si sono estratti questi
+ elenchi.} che ha aggiunto alle \textit{signal safe function} le ulteriori
+funzioni di fig.~\ref{fig:sig_safe_functions_posix_2016}.
\begin{figure}[!htb]
\end{figure}
Rispetto a questi elenchi occorre precisare che prima della versione 2.24
-delle \acr{glibc} l'implementazione delle funzioni \fork{execl} ed
-\fork{execle} non era sicura, e che tuttora non lo è quella di
+delle \acr{glibc} l'implementazione delle funzioni \func{execl} ed
+\func{execle} non era sicura, e che tuttora non lo è quella di
\func{aio\_suspend}. Inoltre è da evitare \func{fork}, che potrebbe essere
rimossa in future revisioni dello standard, e che già POSIX-1.2003 indicava
come tale se usata in concorrenza con \func{pthread\_atfork}.
\constd{SIGRTMIN} e \constd{SIGRTMAX}, che specificano il numero minimo e
massimo associato ad un segnale \textit{real-time}.
-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 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
- per la nuova NTPL (\textit{New Thread Posix Library}), il che comporta che
- \const{SIGRTMIN} a seconda dei casi può assumere i valori 34 o 35.}
+Su Linux i segnali \textit{real-time} vengono numerati a partire da 32, fino
+ad un valore massimo di 64, per un totale di 33 segnali disponibili, contro
+gli almeno 8 richiesti da POSIX.1b. Si tenga 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} fornito
+quando si usano le \acr{glibc} viene modificato di conseguenza.\footnote{per
+ la precisione vengono usati i primi tre per la vecchia implementazione dei
+ \textit{LinuxThread} ed i primi due per la nuova NTPL (\textit{New Thread
+ Posix Library}), il che comporta che \const{SIGRTMIN} a seconda dei casi
+ può assumere i valori 34 o 35.}
Per questo motivo nei programmi che usano i segnali \textit{real-time} non si
-deve mai usare un valore assoluto dato che si correrebbe il rischio di
-utilizzare un segnale in uso alle librerie, ed il numero del segnale deve
-invece essere sempre specificato in forma relativa a \const{SIGRTMIN} (come
-\code{SIGRTMIN + n}) avendo inoltre cura di controllare di non aver mai
-superato \const{SIGRTMAX}.
-
-I segnali con un numero più basso hanno una priorità maggiore e vengono
-consegnati per primi, inoltre i segnali \textit{real-time} non possono
-interrompere l'esecuzione di un gestore di un segnale a priorità più alta; la
-loro azione predefinita è quella di terminare il programma. I segnali
-ordinari hanno tutti la stessa priorità, che è più alta di quella di qualunque
-segnale \textit{real-time}. Lo standard non definisce niente al riguardo ma
-Linux, come molte altre implementazioni, adotta questa politica.
+deve mai usare un valore numerico assoluto, dato che si potrebbe correre il
+rischio di utilizzare un segnale già in uso alle librerie; il numero del
+segnale deve invece essere sempre specificato in forma relativa a
+\const{SIGRTMIN}, con qualcosa come \code{SIGRTMIN + n}, avendo sempre cura di
+controllare di non aver indicato un valore maggiore di \const{SIGRTMAX}.
+
+I segnali \textit{real-time} con un numero più basso hanno una priorità
+maggiore e vengono consegnati per primi, inoltre i segnali \textit{real-time}
+non possono interrompere l'esecuzione di un gestore di un segnale a priorità
+più alta. La loro azione predefinita è sempre quella di terminare il
+programma. I segnali ordinari invece hanno tutti la stessa priorità, che è
+più alta di quella di qualunque segnale \textit{real-time}.\footnote{questa è
+ però una caratteristica di Linux, presente comunque anche nella gran parte
+ degli altri kernel \textit{unix-like}, lo standard infatti non definisce
+ niente al riguardo.}
Si tenga presente che questi nuovi segnali non sono associati a nessun evento
-specifico, a meno di non richiedere specificamente il loro utilizzo in
+specifico, a meno di non avere richiesto l'utilizzo di uno di essi in
meccanismi di notifica come quelli per l'I/O asincrono (vedi
sez.~\ref{sec:file_asyncronous_io}) o per le code di messaggi POSIX (vedi
-sez.~\ref{sec:ipc_posix_mq}), pertanto devono essere inviati esplicitamente.
+sez.~\ref{sec:ipc_posix_mq}), pertanto nell'uso ordinario devono essere
+inviati esplicitamente.
-Inoltre, per poter usufruire della capacità di restituire dei dati, i relativi
-gestori devono essere installati con \func{sigaction}, specificando per
-\var{sa\_flags} la modalità \const{SA\_SIGINFO} che permette di utilizzare la
-forma estesa \var{sa\_sigaction} del gestore (vedi
+Inoltre, per poter usufruire della loro capacità di restituire dei dati, i
+relativi gestori devono essere installati con \func{sigaction}, specificando
+per \var{sa\_flags} la modalità \const{SA\_SIGINFO} che permette di utilizzare
+la forma estesa \var{sa\_sigaction} del gestore (vedi
sez.~\ref{sec:sig_sigaction}). In questo modo tutti i segnali
\textit{real-time} possono restituire al gestore una serie di informazioni
aggiuntive attraverso l'argomento \struct{siginfo\_t}, la cui definizione è
stata già vista in fig.~\ref{fig:sig_siginfo_t}, nella trattazione dei gestori
in forma estesa.
-In particolare i campi 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,
-mentre per la restituzione dei dati viene usato il campo \var{si\_value}.
+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 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, identificato con il tipo di dato \type{sigval\_t}, è una
-\dirct{union} di tipo \struct{sigval} (la sua definizione è in
-fig.~\ref{fig:sig_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
\textit{thread}, compreso quello dedicato alla gestione, che potrebbe
riceverlo fra due chiamate successive.
+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. Si sono trascurati i controlli dei valori di ritorno delle varie
+funzioni per brevità.
+
+\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}
+
+Dopo aver definito (\texttt{\small 5}) una variabile \var{value} di tipo
+\type{sigval\_t} per inviare i dati, ed 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}).
+
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/rtsigvalsend_handl.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice del gestore.}
+ \label{fig:sig_rtsival_handl}
+\end{figure}
+
+
+
+
\subsection{La gestione avanzata delle temporizzazioni}
\label{sec:sig_timer_adv}
% 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