call} quando vengono interrotte dal suddetto
segnale, riproduce cioè il comportamento standard
di BSD.\\
- \constd{SA\_RESTORER} & Ad uso delle implementazioni delle liberie del C,
+ \constd{SA\_RESTORER} & Ad uso delle implementazioni delle librerie del C,
non deve essere usato nelle applicazioni, serve ad
indicare che il campo \var{sa\_restorer} contiene
l'indirizzo di un cosiddetto \textit{signal
sez.~\ref{sec:sig_real_time}); in precedenza era possibile ottenere alcune
informazioni addizionali usando \var{sa\_handler} con un secondo parametro
addizionale di tipo \var{sigcontext}, che adesso è deprecato.} da
-specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO},
-rispettivamente attraverso i campi \var{sa\_sigaction} o \var{sa\_handler}.
-Quest'ultima è quella classica usata anche con \func{signal}, mentre la prima
-permette di usare un gestore più complesso, in grado di ricevere informazioni
-più dettagliate dal sistema, attraverso la struttura \struct{siginfo\_t},
-riportata in fig.~\ref{fig:sig_siginfo_t}. I due campi devono essere usati in
-maniera alternativa, in certe implementazioni questi campi vengono addirittura
+specificare rispettivamente attraverso i campi \var{sa\_sigaction} o
+\var{sa\_handler}, a seconda dell'uso o meno del flag \const{SA\_SIGINFO}. La
+forma con \var{sa\_handler} è quella classica usata anche con \func{signal},
+mentre quella con \var{sa\_sigaction} permette di usare un gestore più
+complesso, in grado di ricevere informazioni più dettagliate dal sistema
+attraverso la struttura \struct{siginfo\_t}, riportata in
+fig.~\ref{fig:sig_siginfo_t}. I due campi devono essere usati in maniera
+alternativa, in certe implementazioni questi campi vengono addirittura
definiti come una \direct{union}.\footnote{la direttiva \direct{union} del
- linguaggio C definisce una variabile complessa, analoga a una stuttura, i
+ linguaggio C definisce una variabile complessa, analoga a una struttura, i
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 allora 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
In generale \var{si\_code} contiene, per i segnali generici, per quelli
\textit{real-time} e per tutti quelli inviati tramite da un processo con
\func{kill} o affini, le informazioni circa l'origine del segnale stesso, ad
-esempio se generato dal kernel, da un timer, da \func{kill}, ecc. Il valore
-viene sempre espresso come una costante,\footnote{le definizioni di tutti i
- valori possibili si trovano in \file{bits/siginfo.h}.} ed i valori possibili
-in questo caso sono riportati in tab.~\ref{tab:sig_si_code_generic}.
+esempio se generato dal kernel, da un timer, da \func{kill}, ecc. Il valore di
+\var{si\_code} viene sempre espresso come una costante,\footnote{le
+ definizioni di tutti i valori possibili si trovano in
+ \file{bits/siginfo.h}.} ed i valori possibili in questo caso sono riportati
+in tab.~\ref{tab:sig_si_code_generic}.
\begin{table}[!htb]
\footnotesize
controllo (\signal{SIGCHLD}, \signal{SIGTRAP} e \signal{SIGPOLL}) forniscono
altre informazioni specifiche.
-
In questo caso il valore del campo \var{si\_code} deve essere verificato nei
confronti delle diverse costanti previste per ciascuno di detti segnali; dato
che si tratta di costanti, e non di una maschera binaria, i valori numerici
\begin{table}[!htb]
\footnotesize
\centering
- \begin{tabular}[c]{|l|p{8cm}|}
+ \begin{tabular}[c]{|l|p{10cm}|}
\hline
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
\constd{SEGV\_MAPERR} & Indirizzo non mappato.\\
\constd{SEGV\_ACCERR} & Permessi non validi per l'indirizzo.\\
+ \constd{SEGV\_BNDERR} & Controllo sui limiti di accesso (via MPX) fallito
+ (dal 3.19).\\
+ \constd{SEGV\_PKUERR} & Accesso negato da una protezione della memoria,
+ vedi sez.~\ref{sec:procadv_security_misc} (dal
+ 4.6).\\
\hline
\constd{BUS\_ADRALN} & Allineamento dell'indirizzo non valido.\\
\constd{BUS\_ADRERR} & Indirizzo fisico inesistente.\\
- \constd{BUS\_OBJERR} & Errore hardware sull'indirizzo.\\
+ \constd{BUS\_OBJERR} & Errore hardware specifico sull'indirizzo.\\
+ \constd{BUS\_MCEERR\_AR}& Rilevata corruzione sulla memoria utilizzata
+ direttamente dal processo è richiesta un'azione.\\
+ \constd{BUS\_MCEERR\_AO}& Rilevata corruzione sulla memoria su memoria non
+ utilizzata direttamente dal processo, l'azione
+ è opzionale.\\
+ % https://lore.kernel.org/patchwork/patch/158250/
\hline
\constd{TRAP\_BRKPT} & Breakpoint sul processo.\\
\constd{TRAP\_TRACE} & Trappola di tracciamento del processo.\\
+ \constd{TRAP\_BRANCH} & Il processo ha preso una branch trap.\\
+ % https://stackoverflow.com/questions/45895234/what-is-process-branch-trap
+ \constd{TRAP\_HWBKPT} & Breakpoint/watchpoint hardware.\\
\hline
\constd{CLD\_EXITED} & Il figlio è uscito.\\
\constd{CLD\_KILLED} & Il figlio è stato terminato.\\
\constd{CLD\_DUMPED} & Il figlio è terminato in modo anormale.\\
\constd{CLD\_TRAPPED} & Un figlio tracciato ha raggiunto una trappola.\\
\constd{CLD\_STOPPED} & Il figlio è stato fermato.\\
- \constd{CLD\_CONTINUED}& Il figlio è ripartito.\\
+ \constd{CLD\_CONTINUED}& Il figlio è ripartito (dal 2.6.9).\\
\hline
\constd{POLL\_IN} & Disponibili dati in ingresso.\\
\constd{POLL\_OUT} & Spazio disponibile sul buffer di uscita.\\
\constd{POLL\_PRI} & Disponibili dati di alta priorità in ingresso.\\
\constd{POLL\_HUP} & Il dispositivo è stato disconnesso.\\
\hline
+ \constd{SYS\_SECCOMP}& Innescato da una regola di \func{seccomp}, vedi
+ sez.~\ref{sec:procadv_seccomp} (dal 3.5).\\
+ \hline
\end{tabular}
\caption{Valori del campo \var{si\_code} della struttura \struct{sigaction}
impostati rispettivamente dai segnali \signal{SIGILL}, \signal{SIGFPE},
- \signal{SIGSEGV}, \signal{SIGBUS}, \signal{SIGCHLD}, \signal{SIGTRAP} e
- \signal{SIGPOLL}/\signal{SIGIO}.}
+ \signal{SIGSEGV}, \signal{SIGBUS}, \signal{SIGCHLD}, \signal{SIGTRAP},
+ \signal{SIGPOLL}/\signal{SIGIO} e \signal{SIGSYS}.}
\label{tab:sig_si_code_special}
\end{table}
del codice, appesantendo inutilmente il programma. Originariamente questo
comportamento veniva ottenuto con delle macro, ma queste hanno tutta una serie
di problemi di sintassi nel passaggio degli argomenti (si veda ad esempio
-\cite{PratC}) che in questo modo possono essere evitati.
+\cite{PratC}) che in questo modo possono essere evitati.
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 un
-segnale durante l'esecuzione di una sezione di codice, lo si può bloccare
-esplicitamente modificando la maschera dei segnali del processo con la
-funzione di sistema \funcd{sigprocmask}, il cui prototipo è:
+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 è:
\begin{funcproto}{
\fhead{signal.h}
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.
+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}.
\begin{table}[htb]
\footnotesize
\label{tab:sig_procmask_how}
\end{table}
-In questo modo diventa possibile proteggere delle sezioni di codice bloccando
-l'insieme di segnali voluto per poi riabilitarli alla fine della sezione
-critica. La funzione permette di 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 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.
+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
+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.
Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
dei casi di \textit{race condition} restano aperte alcune possibilità legate
ottenere un'implementazione, riportata in fig.~\ref{fig:sig_sleep_ok} che non
presenta neanche questa necessità.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/sleep.c}
di un gestore di segnali la stessa funzione che dal segnale è stata
interrotta.
+Ad esempio se consideriamo le funzioni dell'I/O standard di
+sez.~\ref{sec:files_std_interface} è chiaro che essendo basate sull'uso da
+parte delle librerie del C di buffer e puntatori interni, che possono essere
+stati aggiornati in maniera parziale alla ricezione di un segnale, questi
+possono trovarsi, quando riutilizzate all'interno di un gestore, in uno stato
+completamente inconsistente.
+
\index{funzioni!\textit{signal safe}|(}
-Il concetto è comunque più generale e porta ad una distinzione fra quelle che
+Il concetto è comunque generale e porta ad una distinzione fra quelle che
POSIX chiama \textsl{funzioni insicure} (\textit{signal unsafe function}) e
-\textsl{funzioni sicure} (o più precisamente \textit{signal safe function}).
-Quando un segnale interrompe una funzione insicura ed il gestore chiama al suo
-interno una funzione insicura il sistema può dare luogo ad un comportamento
-indefinito, la cosa non avviene invece per le funzioni sicure.
-
-Tutto questo significa che la funzione che si usa come gestore di segnale deve
-essere programmata con molta cura per evirare questa evenienza e che non è
-possibile utilizzare al suo interno una qualunque funzione di sistema, se si
-vogliono evitare questi problemi si può ricorrere soltanto all'uso delle
-funzioni considerate sicure.
-
-L'elenco delle funzioni considerate sicure varia a seconda della
-implementazione utilizzata e dello standard a cui si fa riferimento. Non è
-riportata una lista specifica delle funzioni sicure per Linux, e si suppone
-pertanto che siano quelle richieste dallo standard. Secondo quanto richiesto
-dallo standard POSIX 1003.1 nella revisione del 2003, le ``\textit{signal safe
- function}'' che possono essere chiamate anche all'interno di un gestore di
-segnali sono tutte quelle della lista riportata in
-fig.~\ref{fig:sig_safe_functions}.
+\textsl{funzioni sicure} (o più precisamente \textit{signal safe function} o
+funzioni \textit{async-signal-safe}). Quando un segnale interrompe una
+funzione insicura ed il gestore chiama al suo interno una funzione insicura il
+sistema può dare luogo ad un comportamento indefinito, la cosa non avviene
+invece per le funzioni sicure.
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:sig_safe_functions}
\end{figure}
-\index{funzioni!\textit{signal safe}|)}
+Tutto questo significa che la funzione che si usa come gestore di segnale deve
+essere programmata con molta cura per evirare questa evenienza e che non è
+possibile utilizzare al suo interno una qualunque funzione di sistema o di
+libreria. Oltre ovviamente ad essere rientrante rispetto all'uso di eventuali
+variabili globali del programma se si vogliono evitare questi problemi
+all'interno di un gestore di segnali si dovrà ricorrere soltanto all'uso delle
+funzioni considerate sicure.\footnote{in realtà sarebbe possibile adottare
+ come approccio alternativo quello di bloccare i segnali nel programma
+ principale tutte le volte che questo chiama funzioni insicure o utilizza
+ dati globali utilizzati anche dal gestore di segnali per poi riabilitarli
+ una volta finito; la complessità di questo approccio lo rende però
+ sostanzialmente impraticabile, ed effettivamente non impraticato.}
+
+L'elenco delle funzioni considerate sicure varia a seconda della
+implementazione utilizzata e dello standard a cui si fa riferimento. Non è
+riportata una lista specifica delle funzioni di sistema sicure per Linux, e si
+suppone pertanto che siano quelle richieste dallo standard. Secondo quanto
+richiesto dallo standard POSIX 1003.1 nella revisione del 2003, le
+``\textit{signal safe function}'' che possono essere chiamate anche
+all'interno di un gestore di segnali sono tutte quelle della lista riportata
+in fig.~\ref{fig:sig_safe_functions}.
Lo standard POSIX.1-2004 modifica la lista di
fig.~\ref{fig:sig_safe_functions} aggiungendo le funzioni \func{\_Exit} e
\label{fig:sig_safe_functions_posix_2008}
\end{figure}
+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{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]
+ \footnotesize \centering
+ \begin{minipage}[c]{14cm}
+ \func{ffs}, \func{htonl}, \func{htons}, \func{longjmp}, \func{memccpy},
+ \func{memchr}, \func{memcmp}, \func{memcpy}, \func{memmove}, \func{memset},
+ \func{siglongjmp}, \func{stpcpy}, \func{stpncpy}, \func{strcat},
+ \func{strchr}, \func{strcmp}, \func{strcpy}, \func{strcspn},
+ \func{strlen}, \func{strncat}, \func{strncmp}, \func{strncpy},
+ \func{strnlen}, \func{strpbrk}, \func{strrchr}, \func{strspn},
+ \func{strstr}, \func{strtok\_r}, \func{wcpcpy}, \func{wcpncpy},
+ \func{wcscat}, \func{wcschr}, \func{wcscmp}, \func{wcscpy},
+ \func{wcscspn}, \func{wcslen}, \func{wcsncat}, \func{wcsncmp},
+ \func{wcsncpy}, \func{wcsnlen}, \func{wcspbrk}, \func{wcsrchr},
+ \func{wcsspn}, \func{wcsstr}, \func{wcstok}, \func{wmemchr},
+ \func{wmemcmp}, \func{wmemcpy}, \func{wmemmove}, \func{wmemset}.
+ \end{minipage}
+ \normalsize
+ \caption{Ulteriori funzioni sicure secondo lo standard POSIX.1-2016.}
+ \label{fig:sig_safe_functions_posix_2016}
+\end{figure}
+
+Rispetto a questi elenchi occorre precisare che prima della versione 2.24
+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}.
+
+\index{funzioni!\textit{signal safe}|)}
Per questo motivo è opportuno mantenere al minimo indispensabile le operazioni
effettuate all'interno di un gestore di segnali, qualora si debbano compiere
\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
+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.
\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
+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}).
% 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
+% LocalWords: sigorset sigandset BOOTTIME Android request remain cap dell'
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+% LocalWords: IPC dest left right trampoline BNDERR MPX PKUERR MCEERR async
+% LocalWords: BRANCH branch HWBKPT watchpoint SECCOMP seccomp wrapper pidfd
+% LocalWords: fchdir sigmask safety
projects / gapil.git / blobdiff