X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=51ec560caf379e1f5b4ef5c4181efc0aafb02afe;hp=89b20cad732ca3d7832babc7ff763c539eaae300;hb=c474f4307db945bc45287edd0ea4c2c29374d0ee;hpb=687f101ae37d793ffda23c39ca8735e127b5fc9d diff --git a/signal.tex b/signal.tex index 89b20ca..51ec560 100644 --- a/signal.tex +++ b/signal.tex @@ -92,7 +92,7 @@ in tutti quei casi in cui si vuole che esso resti attivo. In questo caso è possibile una situazione in cui i segnali possono essere perduti. Si consideri il segmento di codice riportato in -\secref{fig:sig_old_handler}, nel programma principale viene installato un +fig.~\ref{fig:sig_old_handler}, nel programma principale viene installato un gestore (\texttt{\small 5}), ed in quest'ultimo la prima operazione (\texttt{\small 11}) è quella di reinstallare se stesso. Se nell'esecuzione del gestore un secondo segnale arriva prima che esso abbia potuto eseguire la @@ -117,7 +117,7 @@ Questa semantica viene chiamata \textsl{inaffidabile}; infatti la ricezione del segnale e la reinstallazione del suo gestore non sono operazioni atomiche, e sono sempre possibili delle race condition\index{race condition} -(sull'argomento vedi quanto detto in \secref{sec:proc_multi_prog}). +(sull'argomento vedi quanto detto in sez.~\ref{sec:proc_multi_prog}). Un'altro problema è che in questa semantica non esiste un modo per bloccare i segnali quando non si vuole che arrivino; i processi possono ignorare il @@ -130,7 +130,7 @@ tutti i problemi precedenti. In questa semantica i segnali vengono \textsl{generati} dal kernel per un processo all'occorrenza dell'evento che causa il segnale. In genere questo viene fatto dal kernel impostando l'apposito campo della \struct{task\_struct} del processo nella process table (si veda -\figref{fig:proc_task_struct}). +fig.~\ref{fig:proc_task_struct}). Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese \textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre @@ -149,7 +149,7 @@ ignorarlo. Si tenga presente che il kernel stabilisce cosa fare con un segnale che è stato bloccato al momento della consegna, non quando viene generato; questo consente di cambiare l'azione per il segnale prima che esso venga consegnato, -e si può usare la funzione \func{sigpending} (vedi \secref{sec:sig_sigmask}) +e si può usare la funzione \func{sigpending} (vedi sez.~\ref{sec:sig_sigmask}) per determinare quali segnali sono bloccati e quali sono pendenti. @@ -239,21 +239,21 @@ una delle tre possibilit \end{itemize*} Un programma può specificare queste scelte usando le due funzioni -\func{signal} e \func{sigaction} (vedi \secref{sec:sig_signal} e -\secref{sec:sig_sigaction}). Se si è installato un gestore sarà +\func{signal} e \func{sigaction} (vedi sez.~\ref{sec:sig_signal} e +sez.~\ref{sec:sig_sigaction}). Se si è installato un gestore sarà quest'ultimo ad essere eseguito alla notifica del segnale. Inoltre il sistema farà si che mentre viene eseguito il gestore di un segnale, quest'ultimo venga automaticamente bloccato (così si possono evitare race condition\index{race condition}). Nel caso non sia stata specificata un'azione, viene utilizzata l'azione -standard che (come vedremo in \secref{sec:sig_standard}) è propria di ciascun +standard che (come vedremo in sez.~\ref{sec:sig_standard}) è propria di ciascun segnale; nella maggior parte dei casi essa porta alla terminazione del processo, ma alcuni segnali che rappresentano eventi innocui vengono ignorati. Quando un segnale termina un processo, il padre può determinare la causa della terminazione esaminando il codice di stato riportato delle funzioni -\func{wait} e \func{waitpid} (vedi \secref{sec:proc_wait}); questo è il modo +\func{wait} e \func{waitpid} (vedi sez.~\ref{sec:proc_wait}); questo è il modo in cui la shell determina i motivi della terminazione di un programma e scrive un eventuale messaggio di errore. @@ -289,7 +289,7 @@ che concernono i segnali sono definiti nell'header di sistema \file{signal.h}. Il numero totale di segnali presenti è dato dalla macro \const{NSIG}, e dato che i numeri dei segnali sono allocati progressivamente, essa corrisponde anche al successivo del valore numerico assegnato all'ultimo segnale definito. -In \tabref{tab:sig_signal_list} si è riportato l'elenco completo dei segnali +In tab.~\ref{tab:sig_signal_list} si è riportato l'elenco completo dei segnali definiti in Linux (estratto dalle pagine di manuale), comparati con quelli definiti in vari standard. @@ -311,16 +311,16 @@ definiti in vari standard. \hline \end{tabular} \caption{Legenda delle azioni predefinite dei segnali riportate in - \tabref{tab:sig_signal_list}.} + tab.~\ref{tab:sig_signal_list}.} \label{tab:sig_action_leg} \end{table} -In \tabref{tab:sig_signal_list} si sono anche riportate le azioni predefinite +In tab.~\ref{tab:sig_signal_list} si sono anche riportate le azioni predefinite di ciascun segnale (riassunte con delle lettere, la cui legenda completa è in -\tabref{tab:sig_action_leg}), quando nessun gestore è installato un +tab.~\ref{tab:sig_action_leg}), quando nessun gestore è installato un segnale può essere ignorato o causare la terminazione del processo. Nella colonna standard sono stati indicati anche gli standard in cui ciascun segnale -è definito, secondo lo schema di \tabref{tab:sig_standard_leg}. +è definito, secondo lo schema di tab.~\ref{tab:sig_standard_leg}. \begin{table}[htb] @@ -338,7 +338,7 @@ colonna standard sono stati indicati anche gli standard in cui ciascun segnale \hline \end{tabular} \caption{Legenda dei valori della colonna \textbf{Standard} di - \tabref{tab:sig_signal_list}.} + tab.~\ref{tab:sig_signal_list}.} \label{tab:sig_standard_leg} \end{table} @@ -589,7 +589,7 @@ L'azione predefinita avuto successo. \item[\const{SIGURG}] Questo segnale è inviato quando arrivano dei dati urgenti o \textit{out-of-band} su di un socket\index{socket}; per maggiori - dettagli al proposito si veda \secref{sec:TCP_urgent_data}. + dettagli al proposito si veda sez.~\ref{sec:TCP_urgent_data}. \item[\const{SIGPOLL}] Questo segnale è equivalente a \const{SIGIO}, è definito solo per compatibilità con i sistemi System V. \end{basedescript} @@ -604,7 +604,7 @@ cui si trattano gli argomenti relativi. Questi segnali sono: \begin{basedescript}{\desclabelwidth{2.0cm}} \item[\const{SIGCHLD}] Questo è il segnale mandato al processo padre quando un figlio termina o viene fermato. L'azione predefinita è di ignorare il - segnale, la sua gestione è trattata in \secref{sec:proc_wait}. + segnale, la sua gestione è trattata in sez.~\ref{sec:proc_wait}. \item[\const{SIGCLD}] Per Linux questo è solo un segnale identico al precedente, il nome è obsoleto e andrebbe evitato. \item[\const{SIGCONT}] Il nome sta per \textit{continue}. Il segnale viene @@ -622,7 +622,7 @@ cui si trattano gli argomenti relativi. Questi segnali sono: se viene fermato e riavviato, come per esempio riscrivere un prompt, o inviare un avviso. \item[\const{SIGSTOP}] Il segnale ferma un processo (lo porta cioè in uno - stato di sleep, vedi \secref{sec:proc_sched}); il segnale non può essere né + stato di sleep, vedi sez.~\ref{sec:proc_sched}); il segnale non può essere né intercettato, né ignorato, né bloccato. \item[\const{SIGTSTP}] Il nome sta per \textit{interactive stop}. Il segnale ferma il processo interattivamente, ed è generato dal carattere SUSP @@ -636,11 +636,12 @@ cui si trattano gli argomenti relativi. Questi segnali sono: sessione di lavoro in \textit{background}. Quando un processo in background tenta di leggere da un terminale viene inviato questo segnale a tutti i processi della sessione di lavoro. L'azione predefinita è di fermare il - processo. L'argomento è trattato in \secref{sec:sess_job_control_overview}. + processo. L'argomento è trattato in + sez.~\ref{sec:sess_job_control_overview}. \item[\const{SIGTTOU}] Segnale analogo al precedente \const{SIGTTIN}, ma generato quando si tenta di scrivere o modificare uno dei modi del terminale. L'azione predefinita è di fermare il processo, l'argomento è - trattato in \secref{sec:sess_job_control_overview}. + trattato in sez.~\ref{sec:sess_job_control_overview}. \end{basedescript} @@ -658,7 +659,7 @@ segnali sono: \item[\const{SIGPIPE}] Sta per \textit{Broken pipe}. Se si usano delle pipe, (o delle FIFO o dei socket) è necessario, prima che un processo inizi a scrivere su una di esse, che un'altro l'abbia aperta in lettura (si veda - \secref{sec:ipc_pipes}). Se il processo in lettura non è partito o è + sez.~\ref{sec:ipc_pipes}). Se il processo in lettura non è partito o è terminato inavvertitamente alla scrittura sulla pipe il kernel genera questo segnale. Se il segnale è bloccato, intercettato o ignorato la chiamata che lo ha causato fallisce, restituendo l'errore \errcode{EPIPE}. @@ -667,11 +668,11 @@ segnali sono: situazione precedente. \item[\const{SIGXCPU}] Sta per \textit{CPU time limit exceeded}. Questo segnale è generato quando un processo eccede il limite impostato per il - tempo di CPU disponibile, vedi \secref{sec:sys_resource_limit}. + tempo di CPU disponibile, vedi sez.~\ref{sec:sys_resource_limit}. \item[\const{SIGXFSZ}] Sta per \textit{File size limit exceeded}. Questo segnale è generato quando un processo tenta di estendere un file oltre le dimensioni specificate dal limite impostato per le dimensioni massime di un - file, vedi \secref{sec:sys_resource_limit}. + file, vedi sez.~\ref{sec:sys_resource_limit}. \end{basedescript} @@ -710,7 +711,7 @@ quando si vuole notificare all'utente il segnale ricevuto (nel caso di terminazione di un processo figlio o di un gestore che gestisce più segnali); la prima funzione, \funcd{strsignal}, è una estensione GNU, accessibile avendo definito \macro{\_GNU\_SOURCE}, ed è analoga alla funzione \func{strerror} (si -veda \secref{sec:sys_strerror}) per gli errori: +veda sez.~\ref{sec:sys_strerror}) per gli errori: \begin{prototype}{string.h}{char *strsignal(int signum)} Ritorna il puntatore ad una stringa che contiene la descrizione del segnale \param{signum}. @@ -721,7 +722,7 @@ di \func{strsignal}. Nel caso si debba mantenere traccia del messaggio sar necessario copiarlo. La seconda funzione, \funcd{psignal}, deriva da BSD ed è analoga alla funzione -\func{perror} descritta sempre in \secref{sec:sys_strerror}; il suo prototipo +\func{perror} descritta sempre in sez.~\ref{sec:sys_strerror}; il suo prototipo è: \begin{prototype}{signal.h}{void psignal(int sig, const char *s)} Stampa sullo standard error un messaggio costituito dalla stringa \param{s}, @@ -758,21 +759,21 @@ processo alla loro occorrenza. \subsection{Il comportamento generale del sistema.} \label{sec:sig_gen_beha} -Abbiamo già trattato in \secref{sec:sig_intro} le modalità con cui il sistema +Abbiamo già trattato in sez.~\ref{sec:sig_intro} le modalità con cui il sistema gestisce l'interazione fra segnali e processi, ci resta da esaminare però il comportamento delle system call; in particolare due di esse, \func{fork} ed \func{exec}, dovranno essere prese esplicitamente in considerazione, data la loro stretta relazione con la creazione di nuovi processi. -Come accennato in \secref{sec:proc_fork} quando viene creato un nuovo processo -esso eredita dal padre sia le azioni che sono state impostate per i singoli -segnali, che la maschera dei segnali bloccati (vedi \secref{sec:sig_sigmask}). -Invece tutti i segnali pendenti e gli allarmi vengono cancellati; essi infatti -devono essere recapitati solo al padre, al figlio dovranno arrivare solo i -segnali dovuti alle sue azioni. +Come accennato in sez.~\ref{sec:proc_fork} quando viene creato un nuovo +processo esso eredita dal padre sia le azioni che sono state impostate per i +singoli segnali, che la maschera dei segnali bloccati (vedi +sez.~\ref{sec:sig_sigmask}). Invece tutti i segnali pendenti e gli allarmi +vengono cancellati; essi infatti devono essere recapitati solo al padre, al +figlio dovranno arrivare solo i segnali dovuti alle sue azioni. Quando si mette in esecuzione un nuovo programma con \func{exec} (si ricordi -quanto detto in \secref{sec:proc_exec}) tutti i segnali per i quali è stato +quanto detto in sez.~\ref{sec:proc_exec}) tutti i segnali per i quali è stato installato un gestore vengono reimpostati a \const{SIG\_DFL}. Non ha più senso infatti fare riferimento a funzioni definite nel programma originario, che non sono presenti nello spazio di indirizzi del nuovo programma. @@ -806,7 +807,7 @@ presenta questa situazione \item la scrittura sugli stessi file, nel caso in cui dati non possano essere accettati immediatamente. \item l'apertura di un file di dispositivo che richiede operazioni non - immediate per una una risposta. + immediate per una risposta. \item le operazioni eseguite con \func{ioctl} che non è detto possano essere eseguite immediatamente. \item le funzioni di intercomunicazione che si bloccano in attesa di risposte @@ -838,7 +839,7 @@ condizione. Linux e le \acr{glibc} consentono di utilizzare entrambi gli approcci, attraverso una opportuna opzione di \func{sigaction} (vedi -\secref{sec:sig_sigaction}). È da chiarire comunque che nel caso di +sez.~\ref{sec:sig_sigaction}). È da chiarire comunque che nel caso di interruzione nel mezzo di un trasferimento parziale di dati, le system call ritornano sempre indicando i byte trasferiti. @@ -854,7 +855,7 @@ ogni implementazione successiva ne ha modificato e ridefinito il comportamento, pur mantenendone immutato il prototipo\footnote{in realtà in alcune vecchie implementazioni (SVr4 e 4.3+BSD in particolare) vengono usati alcuni parametri aggiuntivi per definire il comportamento della funzione, - vedremo in \secref{sec:sig_sigaction} che questo è possibile usando la + vedremo in sez.~\ref{sec:sig_sigaction} che questo è possibile usando la funzione \func{sigaction}.} che è: \begin{prototype}{signal.h} {sighandler\_t signal(int signum, sighandler\_t handler)} @@ -886,7 +887,7 @@ un puntatore a una funzione di questo tipo, che segnale. Il numero di segnale passato in \param{signum} può essere indicato -direttamente con una delle costanti definite in \secref{sec:sig_standard}. Il +direttamente con una delle costanti definite in sez.~\ref{sec:sig_standard}. Il gestore \param{handler} invece, oltre all'indirizzo della funzione da chiamare all'occorrenza del segnale, può assumere anche i due valori costanti \const{SIG\_IGN} con cui si dice ignorare il segnale e \const{SIG\_DFL} per @@ -916,7 +917,7 @@ Al contrario BSD segue la semantica affidabile, non disinstallando il gestore e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo delle \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 \secref{sec:sig_semantics}, può essere ottenuto +per i motivi visti in sez.~\ref{sec:sig_semantics}, può essere ottenuto chiamando \func{sysv\_signal}, una volta che si sia definita la macro \macro{\_XOPEN\_SOURCE}. In generale, per evitare questi problemi, l'uso di \func{signal} (ed ogni eventuale ridefinizine della stessa) è da evitare; @@ -932,7 +933,7 @@ questi segnali pu \subsection{Le funzioni \func{kill} e \func{raise}} \label{sec:sig_kill_raise} -Come accennato in \secref{sec:sig_types}, un segnale può essere generato +Come accennato in sez.~\ref{sec:sig_types}, un segnale può essere generato direttamente da un processo attraverso una opportuna system call. Le funzioni che si usano di solito per inviare un segnale generico sono due, \func{raise} e \func{kill}. @@ -953,7 +954,7 @@ suo prototipo Il valore di \param{sig} specifica il segnale che si vuole inviare e può essere specificato con una delle macro definite in -\secref{sec:sig_classification}. In genere questa funzione viene usata per +sez.~\ref{sec:sig_classification}. In genere questa funzione viene usata per riprodurre il comportamento predefinito di un segnale che sia stato intercettato. In questo caso, una volta eseguite le operazioni volute, il gestore dovrà prima reinstallare l'azione predefinita, per poi attivarla @@ -985,12 +986,12 @@ non viene inviato nessun segnale, ma viene eseguito il controllo degli errori, in tal caso si otterrà un errore \errcode{EPERM} se non si hanno i permessi necessari ed un errore \errcode{ESRCH} se il processo specificato non esiste. Si tenga conto però che il sistema ricicla i \acr{pid} (come accennato in -\secref{sec:proc_pid}) per cui l'esistenza di un processo non significa che +sez.~\ref{sec:proc_pid}) per cui l'esistenza di un processo non significa che esso sia realmente quello a cui si intendeva mandare il segnale. Il valore dell'argomento \param{pid} specifica il processo (o i processi) di destinazione a cui il segnale deve essere inviato e può assumere i valori -riportati in \tabref{tab:sig_kill_values}. +riportati in tab.~\ref{tab:sig_kill_values}. Si noti pertanto che la funzione \code{raise(sig)} può essere definita in termini di \func{kill}, ed è sostanzialmente equivalente ad una @@ -1008,7 +1009,7 @@ Una seconda funzione che pu errore, gli errori sono gli stessi di \func{kill}.} \end{prototype} \noindent e che permette di inviare un segnale a tutto un \textit{process - group} (vedi \secref{sec:sess_proc_group}). + group} (vedi sez.~\ref{sec:sess_proc_group}). \begin{table}[htb] \footnotesize @@ -1037,7 +1038,7 @@ chiamante devono corrispondere all'user-ID reale o all'user-ID salvato della destinazione. Fa eccezione il caso in cui il segnale inviato sia \const{SIGCONT}, nel quale occorre che entrambi i processi appartengano alla stessa sessione. Inoltre, dato il ruolo fondamentale che riveste nel sistema -(si ricordi quanto visto in \secref{sec:sig_termination}), non è possibile +(si ricordi quanto visto in sez.~\ref{sec:sig_termination}), non è possibile inviare al processo 1 (cioè a \cmd{init}) segnali per i quali esso non abbia un gestore installato. @@ -1080,7 +1081,7 @@ controllare se non si cancella un precedente allarme ed eventualmente predisporre le opportune misure per gestire il caso di necessità di più interruzioni. -In \secref{sec:sys_unix_time} abbiamo visto che ad ogni processo sono +In sez.~\ref{sec:sys_unix_time} abbiamo visto che ad ogni processo sono associati tre tempi diversi: il \textit{clock time}, l'\textit{user time} ed il \textit{system time}. Per poterli calcolare il kernel mantiene per ciascun processo tre diversi timer: @@ -1094,7 +1095,7 @@ processo tre diversi timer: \item un \textit{profiling timer} che calcola la somma dei tempi di processore utilizzati direttamente dal processo in user space, e dal kernel nelle system call ad esso relative (che corrisponde a quello che in - \secref{sec:sys_unix_time} abbiamo chiamato \textit{CPU time}). La scadenza + sez.~\ref{sec:sys_unix_time} abbiamo chiamato \textit{CPU time}). La scadenza di questo timer provoca l'emissione di \const{SIGPROF}. \end{itemize} @@ -1121,7 +1122,7 @@ suo prototipo Il valore di \param{which} permette di specificare quale dei tre timer illustrati in precedenza usare; i possibili valori sono riportati in -\tabref{tab:sig_setitimer_values}. +tab.~\ref{tab:sig_setitimer_values}. \begin{table}[htb] \footnotesize \centering @@ -1143,7 +1144,7 @@ illustrati in precedenza usare; i possibili valori sono riportati in Il valore della struttura specificata \param{value} viene usato per impostare il timer, se il puntatore \param{ovalue} non è nullo il precedente valore viene salvato qui. I valori dei timer devono essere indicati attraverso una -struttura \struct{itimerval}, definita in \figref{fig:file_stat_struct}. +struttura \struct{itimerval}, definita in fig.~\ref{fig:file_stat_struct}. La struttura è composta da due membri, il primo, \var{it\_interval} definisce il periodo del timer; il secondo, \var{it\_value} il tempo mancante alla @@ -1171,7 +1172,7 @@ 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} \cite{glibc} che ne riporta la definizione mostrata in -\figref{fig:sig_alarm_def}. +fig.~\ref{fig:sig_alarm_def}. \begin{figure}[!htb] \footnotesize \centering @@ -1199,7 +1200,7 @@ Questo ha una conseguenza che pu conto poi che in caso di sistema molto carico, si può avere il caso patologico in cui un timer scade prima che il segnale di una precedente scadenza sia stato consegnato; in questo caso, per il comportamento dei segnali descritto -in \secref{sec:sig_sigchld}, un solo segnale sarà consegnato. +in sez.~\ref{sec:sig_sigchld}, un solo segnale sarà consegnato. Dato che sia \func{alarm} che \func{setitimer} non consentono di leggere il @@ -1218,7 +1219,7 @@ valore corrente di un timer senza modificarlo, L'ultima funzione che permette l'invio diretto di un segnale è \funcd{abort}; -che, come accennato in \secref{sec:proc_termination}, permette di abortire +che, come accennato in sez.~\ref{sec:proc_termination}, permette di abortire l'esecuzione di un programma tramite l'invio di \const{SIGABRT}. Il suo prototipo è: \begin{prototype}{stdlib.h}{void abort(void)} @@ -1253,7 +1254,7 @@ multitasking un loop di attesa sono apposite funzioni che permettono di mettere un processo in stato di attesa.\footnote{si tratta in sostanza di funzioni che permettono di portare esplicitamente il processo in stato di \textit{sleep}, vedi - \secref{sec:proc_sched}.} + sez.~\ref{sec:proc_sched}.} Il metodo tradizionale per fare attendere ad un processo fino all'arrivo di un segnale è quello di usare la funzione \funcd{pause}, il cui prototipo è: @@ -1297,7 +1298,7 @@ aspettare. In alcune implementazioni inoltre l'uso di \func{sleep} può avere conflitti con quello di \const{SIGALRM}, dato che la funzione può essere realizzata con l'uso di \func{pause} e \func{alarm} (in maniera analoga all'esempio che -vedremo in \secref{sec:sig_example}). In tal caso mescolare chiamata di +vedremo in sez.~\ref{sec:sig_example}). In tal caso mescolare chiamata di \func{alarm} e \func{sleep} o modificare l'azione di \const{SIGALRM}, può causare risultati indefiniti. Nel caso delle \acr{glibc} è stata usata una implementazione completamente indipendente e questi problemi non ci sono. @@ -1342,7 +1343,7 @@ indipendente da \func{alarm}\footnote{nel caso di Linux questo utilizzando direttamente il timer del kernel.} e sia utilizzabile senza interferenze con l'uso di \const{SIGALRM}. La funzione prende come parametri delle strutture di tipo \struct{timespec}, la cui definizione è riportata in -\figref{fig:sys_timeval_struct}, che permettono di specificare un tempo con +fig.~\ref{fig:sys_timeval_struct}, che permettono di specificare un tempo con una precisione (teorica) fino al nanosecondo. La funzione risolve anche il problema di proseguire l'attesa dopo @@ -1372,7 +1373,7 @@ viene evitato, e si raggiungono pause fino ai 2~ms con precisioni del $\mu$s. Un semplice esempio per illustrare il funzionamento di un gestore di segnale è quello della gestione di \const{SIGCHLD}. Abbiamo visto in -\secref{sec:proc_termination} che una delle azioni eseguite dal kernel alla +sez.~\ref{sec:proc_termination} che una delle azioni eseguite dal kernel alla conclusione di un processo è quella di inviare questo segnale al padre.\footnote{in realtà in SVr4 eredita la semantica di System V, in cui il segnale si chiama \const{SIGCLD} e viene trattato in maniera speciale; in @@ -1388,10 +1389,10 @@ gestore per \const{SIGCHLD} il cui unico compito sia quello chiamare \func{waitpid} per completare la procedura di terminazione in modo da evitare la formazione di zombie\index{zombie}. -In \figref{fig:sig_sigchld_handl} è mostrato il codice contenente una +In fig.~\ref{fig:sig_sigchld_handl} è mostrato il codice contenente una implementazione generica di una routine di gestione per \const{SIGCHLD}, (che si trova nei sorgenti allegati nel file \file{SigHand.c}); se ripetiamo i test -di \secref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione +di sez.~\ref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione \cmd{-s} (che si limita ad effettuare l'installazione di questa funzione come gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione di zombie\index{zombie}. @@ -1414,7 +1415,7 @@ di zombie\index{zombie}. \end{figure} Il codice del gestore è di lettura immediata; come buona norma di -programmazione (si ricordi quanto accennato \secref{sec:sys_errno}) si +programmazione (si ricordi quanto accennato sez.~\ref{sec:sys_errno}) si comincia (\texttt{\small 12-13}) con il salvare lo stato corrente di \var{errno}, in modo da poterlo ripristinare prima del ritorno del gestore (\texttt{\small 22-23}). In questo modo si preserva il valore della variabile @@ -1429,8 +1430,8 @@ fondamentale della gestione dei segnali: abbiamo gi generazione di un segnale e l'esecuzione del gestore possa passare un certo lasso di tempo e niente ci assicura che il gestore venga eseguito prima della generazione di ulteriori segnali dello stesso tipo. In questo caso normalmente -i segnali segnali successivi vengono ``\textsl{fusi}'' col primo ed al -processo ne viene recapitato soltanto uno. +i segnali successivi vengono ``\textsl{fusi}'' col primo ed al processo ne +viene recapitato soltanto uno. Questo può essere un caso comune proprio con \const{SIGCHLD}, qualora capiti che molti processi figli terminino in rapida successione. Esso inoltre si @@ -1445,7 +1446,7 @@ resterebbero in stato di zombie\index{zombie} per un tempo indefinito. Per questo occorre ripetere la chiamata di \func{waitpid} fino a che essa non ritorni un valore nullo, segno che non resta nessun processo di cui si debba -ancora ricevere lo stato di terminazione (si veda \secref{sec:proc_wait} per +ancora ricevere lo stato di terminazione (si veda sez.~\ref{sec:proc_wait} per la sintassi della funzione). Si noti anche come la funzione venga invocata con il parametro \const{WNOHANG} che permette di evitare il suo blocco quando tutti gli stati di terminazione sono stati ricevuti. @@ -1471,11 +1472,11 @@ casistica ordinaria. \subsection{Alcune problematiche aperte} \label{sec:sig_example} -Come accennato in \secref{sec:sig_pause_sleep} è possibile implementare +Come accennato in sez.~\ref{sec:sig_pause_sleep} è possibile implementare \func{sleep} a partire dall'uso di \func{pause} e \func{alarm}. A prima vista questo può sembrare di implementazione immediata; ad esempio una semplice versione di \func{sleep} potrebbe essere quella illustrata in -\figref{fig:sig_sleep_wrong}. +fig.~\ref{fig:sig_sleep_wrong}. Dato che è nostra intenzione utilizzare \const{SIGALRM} il primo passo della nostra implementazione di sarà quello di installare il relativo gestore @@ -1509,10 +1510,10 @@ deadlock\index{deadlock}, in quanto \func{pause} non verrebbe mai pi interrotta (se non in caso di un altro segnale). Questo problema può essere risolto (ed è la modalità con cui veniva fatto in -SVr2) usando la funzione \func{longjmp} (vedi \secref{sec:proc_longjmp}) per +SVr2) usando la funzione \func{longjmp} (vedi sez.~\ref{sec:proc_longjmp}) per uscire dal gestore; in questo modo, con una condizione sullo stato di uscita di quest'ultima, si può evitare la chiamata a \func{pause}, usando un -codice del tipo di quello riportato in \figref{fig:sig_sleep_incomplete}. +codice del tipo di quello riportato in fig.~\ref{fig:sig_sleep_incomplete}. \begin{figure}[!htb] \footnotesize \centering @@ -1525,7 +1526,7 @@ codice del tipo di quello riportato in \figref{fig:sig_sleep_incomplete}. \end{figure} In questo caso il gestore (\texttt{\small 18-26}) non ritorna come in -\figref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 24}) per +fig.~\ref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 24}) per rientrare nel corpo principale del programma; dato che in questo caso il valore di uscita di \func{setjmp} è 1, grazie alla condizione in (\texttt{\small 9-12}) si evita comunque che \func{pause} sia chiamata a @@ -1543,7 +1544,7 @@ Un secondo esempio qualche forma di evento; in genere quello che si fa in questo caso è impostare nel gestore un opportuno flag da controllare nel corpo principale del programma (con un codice del tipo di quello riportato in -\figref{fig:sig_event_wrong}). +fig.~\ref{fig:sig_event_wrong}). \begin{figure}[!htb] \footnotesize\centering @@ -1561,11 +1562,11 @@ variabile globale preventivamente inizializzata nel programma principale, il quale potrà determinare, osservandone il contenuto, l'occorrenza o meno del segnale, e prendere le relative azioni conseguenti (\texttt{\small 6-11}). -Questo è il tipico esempio di caso, già citato in \secref{sec:proc_race_cond}, -in cui si genera una race condition\index{race condition}; se infatti il -segnale arriva immediatamente dopo l'esecuzione del controllo (\texttt{\small - 6}) ma prima della cancellazione del flag (\texttt{\small 7}), la sua -occorrenza sarà perduta. +Questo è il tipico esempio di caso, già citato in +sez.~\ref{sec:proc_race_cond}, in cui si genera una race condition\index{race + condition}; se infatti il segnale arriva immediatamente dopo l'esecuzione +del controllo (\texttt{\small 6}) ma prima della cancellazione del flag +(\texttt{\small 7}), la sua occorrenza sarà perduta. Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono funzioni più sofisticate di quelle illustrate finora, che hanno origine dalla @@ -1634,7 +1635,7 @@ comunque eseguite attraverso queste funzioni. In genere si usa un insieme di segnali per specificare quali segnali si vuole bloccare, o per riottenere dalle varie funzioni di gestione la maschera dei -segnali attivi (vedi \secref{sec:sig_sigmask}). Essi possono essere definiti +segnali attivi (vedi sez.~\ref{sec:sig_sigmask}). Essi possono essere definiti in due diverse maniere, aggiungendo i segnali voluti ad un insieme vuoto ottenuto con \func{sigemptyset} o togliendo quelli che non servono da un insieme completo ottenuto con \func{sigfillset}. Infine \func{sigismember} @@ -1645,7 +1646,7 @@ insieme. \subsection{La funzione \func{sigaction}} \label{sec:sig_sigaction} -Abbiamo già accennato in \secref{sec:sig_signal} i problemi di compatibilità +Abbiamo già accennato in sez.~\ref{sec:sig_signal} i problemi di compatibilità relativi all'uso di \func{signal}. Per ovviare a tutto questo lo standard POSIX.1 ha ridefinito completamente l'interfaccia per la gestione dei segnali, rendendola molto più flessibile e robusta, anche se leggermente più complessa. @@ -1688,7 +1689,7 @@ che non consente di ottenere l'azione corrente senza installarne una nuova. Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction}, tramite la quale si specificano tutte le caratteristiche dell'azione associata ad un segnale. Anch'essa è descritta dallo standard POSIX.1 ed in Linux è -definita secondo quanto riportato in \figref{fig:sig_sigaction}. Il campo +definita secondo quanto riportato in fig.~\ref{fig:sig_sigaction}. Il campo \var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere più usato. @@ -1707,19 +1708,19 @@ essere bloccati durante l'esecuzione del gestore, ad essi viene comunque sempre aggiunto il segnale che ne ha causato la chiamata, a meno che non si sia specificato con \var{sa\_flag} un comportamento diverso. Quando il gestore ritorna comunque la maschera dei segnali bloccati (vedi -\secref{sec:sig_sigmask}) viene ripristinata al valore precedente +sez.~\ref{sec:sig_sigmask}) viene ripristinata al valore precedente l'invocazione. L'uso di questo campo permette ad esempio di risolvere il problema residuo dell'implementazione di \code{sleep} mostrata in -\secref{fig:sig_sleep_incomplete}. In quel caso infatti se il segnale di +fig.~\ref{fig:sig_sleep_incomplete}. In quel caso infatti se il segnale di allarme avesse interrotto un altro gestore questo non sarebbe stato eseguito correttamente; la cosa poteva essere prevenuta installando gli altri gestori usando \var{sa\_mask} per bloccare \const{SIGALRM} durante la loro esecuzione. Il valore di \var{sa\_flag} permette di specificare vari aspetti del comportamento di \func{sigaction}, e della reazione del processo ai vari segnali; i valori possibili ed il relativo significato sono riportati -in \tabref{tab:sig_sa_flag}. +in tab.~\ref{tab:sig_sa_flag}. \begin{table}[htb] \footnotesize @@ -1751,17 +1752,17 @@ in \tabref{tab:sig_sa_flag}. \var{sa\_sigaction} al posto di \var{sa\_handler}.\\ \const{SA\_ONSTACK} & Stabilisce l'uso di uno stack alternativo per l'esecuzione del gestore (vedi - \secref{sec:sig_specific_features}).\\ + sez.~\ref{sec:sig_specific_features}).\\ \hline \end{tabular} \caption{Valori del campo \var{sa\_flag} della struttura \struct{sigaction}.} \label{tab:sig_sa_flag} \end{table} -Come si può notare in \figref{fig:sig_sigaction} \func{sigaction} +Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette\footnote{La possibilità è prevista dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x con l'introduzione dei segnali - real-time (vedi \secref{sec:sig_real_time}). In precedenza era possibile + real-time (vedi 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.} di utilizzare due forme diverse di gestore, da specificare, a @@ -1772,7 +1773,7 @@ attraverso i campi \var{sa\_sigaction} o \var{sa\_handler},\footnote{i due è 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 \figref{fig:sig_siginfo_t}. +riportata in fig.~\ref{fig:sig_siginfo_t}. \begin{figure}[!htb] \footnotesize \centering @@ -1804,15 +1805,15 @@ controllo (\const{SIGCHLD}, \const{SIGTRAP} e \const{SIGPOLL}) forniscono altre informazioni specifiche. In tutti i casi il valore del campo è riportato attraverso delle costanti (le cui definizioni si trovano \file{bits/siginfo.h}) il cui elenco dettagliato è disponibile nella pagina di -manuale di di \func{sigaction}. +manuale di \func{sigaction}. Il resto della struttura è definito come \ctyp{union} ed i valori eventualmente presenti dipendono dal segnale, così \const{SIGCHLD} ed i -segnali real-time (vedi \secref{sec:sig_real_time}) inviati tramite +segnali real-time (vedi sez.~\ref{sec:sig_real_time}) inviati tramite \func{kill} avvalorano \var{si\_pid} e \var{si\_uid} coi valori corrispondenti al processo che ha emesso il segnale, \const{SIGILL}, \const{SIGFPE}, \const{SIGSEGV} e \const{SIGBUS} avvalorano \var{si\_addr} con l'indirizzo cui -è avvenuto l'errore, \const{SIGIO} (vedi \secref{sec:file_asyncronous_io}) +è avvenuto l'errore, \const{SIGIO} (vedi sez.~\ref{sec:file_asyncronous_io}) avvalora \var{si\_fd} con il numero del file descriptor e \var{si\_band} per i dati urgenti su un socket\index{socket}. @@ -1847,7 +1848,7 @@ sempre il caso di evitare l'uso di \func{signal} a favore di \func{sigaction}. 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, il cui codice è riportato in -\figref{fig:sig_Signal_code} (il codice completo si trova nel file +fig.~\ref{fig:sig_Signal_code} (il codice completo si trova nel file \file{SigHand.c} nei sorgenti allegati). Si noti come, essendo la funzione estremamente semplice, è definita come \direct{inline}.\footnote{la direttiva \direct{inline} viene usata per dire al compilatore di trattare la funzione @@ -1873,21 +1874,21 @@ estremamente semplice, \textit{signal mask}} \label{sec:sig_sigmask} -Come spiegato in \secref{sec:sig_semantics} tutti i moderni sistemi unix-like +Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like permettono si bloccare temporaneamente (o di eliminare completamente, impostando \const{SIG\_IGN} come azione) la consegna dei segnali ad un processo. Questo è fatto specificando la cosiddetta \textsl{maschera dei segnali} (o \textit{signal mask}) del processo\footnote{nel caso di Linux essa è mantenuta dal campo \var{blocked} della \struct{task\_struct} del processo.} cioè l'insieme dei segnali la cui consegna è bloccata. Abbiamo -accennato in \secref{sec:proc_fork} che la \textit{signal mask} viene +accennato in sez.~\ref{sec:proc_fork} che la \textit{signal mask} viene ereditata dal padre alla creazione di un processo figlio, e abbiamo visto al paragrafo precedente che essa può essere modificata, durante l'esecuzione di un gestore, attraverso l'uso dal campo \var{sa\_mask} di \struct{sigaction}. -Uno dei problemi evidenziatisi con l'esempio di \secref{fig:sig_event_wrong} è -che in molti casi è necessario proteggere delle sezioni di codice (nel caso in -questione la sezione fra il controllo e la eventuale cancellazione del flag +Uno dei problemi evidenziatisi con l'esempio di fig.~\ref{fig:sig_event_wrong} +è che in molti casi è necessario proteggere delle sezioni di codice (nel caso +in questione la sezione fra il controllo e la eventuale cancellazione del flag che testimoniava l'avvenuta occorrenza del segnale) in modo da essere sicuri che essi siano eseguiti senza interruzioni. @@ -1912,7 +1913,7 @@ segnali; il suo prototipo La funzione usa l'insieme di segnali dato all'indirizzo \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 \tabref{tab:sig_procmask_how}. Qualora si specifichi un valore +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. @@ -1941,8 +1942,8 @@ quell'indirizzo. 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 -\secref{fig:sig_event_wrong}, proteggendo la sezione fra il controllo del flag -e la sua cancellazione. +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ò @@ -1952,7 +1953,7 @@ perduta alla conclusione del terminatore. Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte dei casi di race condition\index{race condition} restano aperte alcune possibilità legate all'uso di \func{pause}; il caso è simile a quello del -problema illustrato nell'esempio di \secref{fig:sig_sleep_incomplete}, e cioè +problema illustrato 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 @@ -1974,12 +1975,12 @@ sospensione del processo lo standard POSIX ha previsto la funzione Come esempio dell'uso di queste funzioni proviamo a riscrivere un'altra volta l'esempio di implementazione di \code{sleep}. Abbiamo accennato in -\secref{sec:sig_sigaction} come con \func{sigaction} sia possibile bloccare -\const{SIGALRM} nell'installazione dei gestori degli altri segnali, per -poter usare l'implementazione vista in \secref{fig:sig_sleep_incomplete} senza +sez.~\ref{sec:sig_sigaction} come con \func{sigaction} sia possibile bloccare +\const{SIGALRM} nell'installazione dei gestori degli altri segnali, per poter +usare l'implementazione vista in fig.~\ref{fig:sig_sleep_incomplete} senza interferenze. Questo però comporta una precauzione ulteriore al semplice uso della funzione, vediamo allora come usando la nuova interfaccia è possibile -ottenere un'implementazione, riportata in \figref{fig:sig_sleep_ok} che non +ottenere un'implementazione, riportata in fig.~\ref{fig:sig_sleep_ok} che non presenta neanche questa necessità. \begin{figure}[!htb] @@ -1993,8 +1994,8 @@ presenta neanche questa necessit \end{figure} Per evitare i problemi di interferenza con gli altri segnali in questo caso -non si è usato l'approccio di \figref{fig:sig_sleep_incomplete} evitando l'uso -di \func{longjmp}. Come in precedenza il gestore (\texttt{\small 35-37}) +non si è usato l'approccio di fig.~\ref{fig:sig_sleep_incomplete} evitando +l'uso di \func{longjmp}. Come in precedenza il gestore (\texttt{\small 35-37}) non esegue nessuna operazione, limitandosi a ritornare per interrompere il programma messo in attesa. @@ -2056,7 +2057,7 @@ rispetto a quanto potrebbe essere in un qualunque momento successivo. Una delle caratteristiche di BSD, disponibile anche in Linux, è la possibilità di usare uno stack alternativo per i segnali; è cioè possibile fare usare al sistema un altro stack (invece di quello relativo al processo, vedi -\secref{sec:proc_mem_layout}) solo durante l'esecuzione di un +sez.~\ref{sec:proc_mem_layout}) solo durante l'esecuzione di un gestore. L'uso di uno stack alternativo è del tutto trasparente ai gestori, occorre però seguire una certa procedura: \begin{enumerate} @@ -2065,9 +2066,9 @@ gestori, occorre per \item Usare la funzione \func{sigaltstack} per rendere noto al sistema l'esistenza e la locazione dello stack alternativo. \item Quando si installa un gestore occorre usare \func{sigaction} - specificando il flag \const{SA\_ONSTACK} (vedi \tabref{tab:sig_sa_flag}) per - dire al sistema di usare lo stack alternativo durante l'esecuzione del - gestore. + specificando il flag \const{SA\_ONSTACK} (vedi tab.~\ref{tab:sig_sa_flag}) + per dire al sistema di usare lo stack alternativo durante l'esecuzione del + gestore. \end{enumerate} In genere il primo passo viene effettuato allocando un'opportuna area di @@ -2106,7 +2107,7 @@ Installa un nuovo stack per i segnali. \end{prototype} La funzione prende come argomenti puntatori ad una struttura di tipo -\var{stack\_t}, definita in \figref{fig:sig_stack_t}. I due valori \param{ss} +\var{stack\_t}, definita in fig.~\ref{fig:sig_stack_t}. I due valori \param{ss} e \param{oss}, se non nulli, indicano rispettivamente il nuovo stack da installare e quello corrente (che viene restituito dalla funzione per un successivo ripristino). @@ -2149,7 +2150,7 @@ avviene per lo stack ordinario dei processi, non si accresce automaticamente Si ricordi infine che una chiamata ad una funzione della famiglia \func{exec} cancella ogni stack alternativo. -Abbiamo visto in \secref{fig:sig_sleep_incomplete} come si possa usare +Abbiamo visto in fig.~\ref{fig:sig_sleep_incomplete} come si possa usare \func{longjmp} per uscire da un gestore rientrando direttamente nel corpo del programma; sappiamo però che nell'esecuzione di un gestore il segnale che l'ha invocato viene bloccato, e abbiamo detto che possiamo ulteriormente @@ -2164,7 +2165,7 @@ mentre 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 caratteristiche si sono abilitate con le macro viste in -\secref{sec:intro_gcc_glibc_std}. +sez.~\ref{sec:intro_gcc_glibc_std}. Lo standard POSIX però prevede anche la presenza di altre due funzioni \funcd{sigsetjmp} e \funcd{siglongjmp}, che permettono di decidere quale dei @@ -2179,7 +2180,7 @@ due comportamenti il programma deve assumere; i loro prototipi sono: non-locale su un precedente contesto. \bodydesc{Le due funzioni sono identiche alle analoghe \func{setjmp} e - \func{longjmp} di \secref{sec:proc_longjmp}, ma consentono di specificare + \func{longjmp} di sez.~\ref{sec:proc_longjmp}, ma consentono di specificare il comportamento sul ripristino o meno della maschera dei segnali.} \end{functions} @@ -2187,7 +2188,7 @@ Le due funzioni prendono come primo argomento la variabile su cui viene salvato il contesto dello stack per permettere il salto non-locale \index{salto non-locale}; nel caso specifico essa è di tipo \type{sigjmp\_buf}, e non \type{jmp\_buf} come per le analoghe di -\secref{sec:proc_longjmp} in quanto in questo caso viene salvata anche la +sez.~\ref{sec:proc_longjmp} in quanto in questo caso viene salvata anche la maschera dei segnali. Nel caso di \func{sigsetjmp} se si specifica un valore di \param{savesigs} @@ -2214,7 +2215,7 @@ segnali classici: questo sarà eseguito una sola volta, ed il processo non sarà in grado di accorgersi di quante volte l'evento che ha generato il segnale è accaduto. \item[I segnali non trasportano informazione] - i segnali classici non prevedono prevedono altra informazione sull'evento + i segnali classici non prevedono altra informazione sull'evento che li ha generati se non il fatto che sono stati emessi (tutta l'informazione che il kernel associa ad un segnale è il suo numero). \item[I segnali non hanno un ordine di consegna] @@ -2261,18 +2262,18 @@ real-time. Si tenga presente che questi nuovi segnali non sono associati a nessun evento specifico, a meno di non utilizzarli in meccanismi di notifica come quelli per -l'I/O asincrono (vedi \secref{sec:file_asyncronous_io}) o per le code di -messaggi POSIX (vedi \secref{sec:ipc_posix_mq}); pertanto devono essere +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. 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} (vedi \secref{sec:sig_sigaction}). In questo -modo tutti i segnali real-time possono restituire al gestore una serie di -informazioni aggiuntive attraverso l'argomento \struct{siginfo\_t}, la cui -definizione abbiamo già visto in \figref{fig:sig_siginfo_t}, nella trattazione -dei gestori in forma estesa. +forma estesa \var{sa\_sigaction} (vedi sez.~\ref{sec:sig_sigaction}). In +questo modo tutti i segnali real-time possono restituire al gestore una serie +di informazioni aggiuntive attraverso l'argomento \struct{siginfo\_t}, la cui +definizione abbiamo già visto in fig.~\ref{fig:sig_siginfo_t}, nella +trattazione dei gestori in forma estesa. In particolare i campi utilizzati dai segnali real-time sono \var{si\_pid} e \var{si\_uid} in cui vengono memorizzati rispettivamente il \acr{pid} e @@ -2280,14 +2281,14 @@ l'user-ID effettivo del processo che ha inviato il segnale, mentre per la restituzione dei dati viene usato il campo \var{si\_value}. Questo è una \ctyp{union} di tipo \struct{sigval\_t} (la sua definizione è in -\figref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico, +fig.~\ref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico, se usata nella forma \var{sival\_int}, o un indirizzo, se usata nella forma \var{sival\_ptr}. L'unione viene usata dai segnali real-time e da vari meccanismi di notifica\footnote{un campo di tipo \struct{sigval\_t} è presente anche nella struttura \struct{sigevent} che viene usata dai meccanismi di notifica come quelli per l'I/O asincrono (vedi - \secref{sec:file_asyncronous_io}) o le code di messaggi POSIX (vedi - \secref{sec:ipc_posix_mq}).} per restituire dati al gestore del segnale; in + sez.~\ref{sec:file_asyncronous_io}) o le code di messaggi POSIX (vedi + sez.~\ref{sec:ipc_posix_mq}).} per restituire dati al gestore del segnale; in alcune definizioni essa viene identificata anche come \code{union sigval}. \begin{figure}[!htb] @@ -2334,7 +2335,7 @@ installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili, (vale a dire che c'è posto\footnote{la profondità della coda è indicata dalla costante \const{SIGQUEUE\_MAX}, una della tante costanti di sistema definite dallo standard POSIX che non abbiamo riportato esplicitamente in - \secref{sec:sys_limits}. Il suo valore minimo secondo lo standard, + sez.~\ref{sec:sys_limits}. Il suo valore minimo secondo lo standard, \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux questo è uno dei parametri del kernel impostabili sia con \func{sysctl}, che scrivendolo direttamente in \file{/proc/sys/kernel/rtsig-max}, il valore predefinito è