X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=a5363ec14f4cc3a1d1f863b6bcb29ead58da39fe;hp=a595a54d9d1cd8c8cb29a9c44efc78e3ebe8c7c4;hb=9aad56ecd71e4f36e09f001cdd30b2106beec5c4;hpb=e2a1ad24365266ea8846b688addd4e7694428969 diff --git a/signal.tex b/signal.tex index a595a54..a5363ec 100644 --- a/signal.tex +++ b/signal.tex @@ -143,7 +143,7 @@ moderno) il gestore una volta installato resta attivo e non si hanno 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 \var{task\_struct} del processo nella process table (si veda +campo della \struct{task\_struct} del processo nella process table (si veda \figref{fig:proc_task_struct}). Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese @@ -152,7 +152,7 @@ per tutto il tempo che passa fra la generazione del segnale e la sua consegna esso è detto \textsl{pendente} (o \textit{pending}). In genere questa procedura viene effettuata dallo scheduler\index{scheduler} quando, riprendendo l'esecuzione del processo in questione, verifica la presenza del -segnale nella \var{task\_struct} e mette in esecuzione il gestore. +segnale nella \struct{task\_struct} e mette in esecuzione il gestore. In questa semantica un processo ha la possibilità di bloccare la consegna dei segnali, in questo caso, se l'azione per il suddetto segnale non è quella di @@ -215,7 +215,7 @@ internamente o esternamente al processo. Come accennato quando un segnale viene generato, se la sua azione predefinita non è quella di essere ignorato, il kernel prende nota del fatto nella -\var{task\_struct} del processo; si dice così che il segnale diventa +\struct{task\_struct} del processo; si dice così che il segnale diventa \textsl{pendente} (o \textit{pending}), e rimane tale fino al momento in cui verrà notificato al processo (o verrà specificata come azione quella di ignorarlo). @@ -394,7 +394,8 @@ stato dello stack e delle variabili al momento della ricezione del segnale. \const{SIGPROF} &SL & A & Timer del profiling scaduto \\ \const{SIGSYS} &SL & C & Argomento sbagliato per una subroutine (SVID) \\ \const{SIGTRAP} &SL & C & Trappole per un Trace/breakpoint \\ - \const{SIGURG} &SLB& B & Ricezione di una urgent condition su un socket\\ + \const{SIGURG} &SLB& B & Ricezione di una \textit{urgent condition} su + un socket\index{socket}\\ \const{SIGVTALRM}&SLB& A & Virtual alarm clock \\ \const{SIGXCPU} &SLB& C & Ecceduto il limite sul CPU time \\ \const{SIGXFSZ} &SLB& C & Ecceduto il limite sulla dimensione dei file \\ @@ -431,11 +432,11 @@ proibita) e l'esecuzione non pu In genere si intercettano questi segnali per permettere al programma di terminare in maniera pulita, ad esempio per ripristinare le impostazioni della -console o eliminare i file di lock prima dell'uscita. In questo caso il -gestore deve concludersi ripristinando l'azione predefinita e rialzando il -segnale, in questo modo il programma si concluderà senza effetti spiacevoli, -ma riportando lo stesso stato di uscita che avrebbe avuto se il gestore non ci -fosse stato. +console o eliminare i file di lock\index{file!di lock} prima dell'uscita. In +questo caso il gestore deve concludersi ripristinando l'azione predefinita e +rialzando il segnale, in questo modo il programma si concluderà senza effetti +spiacevoli, ma riportando lo stesso stato di uscita che avrebbe avuto se il +gestore non ci fosse stato. L'azione predefinita per tutti questi segnali è causare la terminazione del processo che li ha causati. In genere oltre a questo il segnale provoca pure @@ -591,12 +592,13 @@ generare questi segnali. L'azione predefinita è di essere ignorati. Questi segnali sono: \begin{basedescript}{\desclabelwidth{2.0cm}} \item[\const{SIGIO}] Questo segnale viene inviato quando un file descriptor è - pronto per eseguire dell'input/output. In molti sistemi solo i socket e i - terminali possono generare questo segnale, in Linux questo può essere usato - anche per i file, posto che la \func{fcntl} abbia avuto successo. + pronto per eseguire dell'input/output. In molti sistemi solo i + socket\index{socket} e i terminali possono generare questo segnale, in Linux + questo può essere usato anche per i file, posto che la \func{fcntl} abbia + avuto successo. \item[\const{SIGURG}] Questo segnale è inviato quando arrivano dei dati - urgenti o \textit{out of band} su di un socket; per maggiori dettagli al - proposito si veda \secref{sec:xxx_urgent_data}. + urgenti o \textit{out of band} su di un socket\index{socket}; per maggiori + dettagli al proposito si veda \secref{sec:xxx_urgent_data}. \item[\const{SIGPOLL}] Questo segnale è equivalente a \const{SIGIO}, è definito solo per compatibilità con i sistemi System V. \end{basedescript} @@ -718,7 +720,7 @@ GNU, accessibile avendo definito \macro{\_GNU\_SOURCE}, ed funzione \func{strerror} (si veda \secref{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 - \var{signum}. + \param{signum}. \end{prototype} \noindent dato che la stringa è allocata staticamente non se ne deve modificare il contenuto, che resta valido solo fino alla successiva chiamata @@ -807,7 +809,8 @@ eseguito prima che la system call sia ritornata. Un elenco dei casi in cui si presenta questa situazione è il seguente: \begin{itemize} \item la lettura da file che possono bloccarsi in attesa di dati non ancora - presenti (come per certi file di dispositivo, i socket o le pipe). + presenti (come per certi file di dispositivo\index{file!di dispositivo}, i + socket\index{socket} o le pipe). \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 @@ -1131,14 +1134,14 @@ illustrati in precedenza usare; i possibili valori sono riportati in \label{tab:sig_setitimer_values} \end{table} -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 \type{itimerval}, definita in \figref{fig:file_stat_struct}. +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}. 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 -scadenza. Entrambi esprimono i tempi tramite una struttura \var{timeval} che +scadenza. Entrambi esprimono i tempi tramite una struttura \struct{timeval} che permette una precisione fino al microsecondo. Ciascun timer decrementa il valore di \var{it\_value} fino a zero, poi invia @@ -1158,8 +1161,8 @@ struct itimerval \end{lstlisting} \end{minipage} \normalsize - \caption{La struttura \type{itimerval}, che definisce i valori dei timer di - sistema.} + \caption{La struttura \structd{itimerval}, che definisce i valori dei timer + di sistema.} \label{fig:sig_itimerval} \end{figure} @@ -1345,7 +1348,7 @@ Lo standard richiede che la funzione sia implementata in maniera del tutto indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto 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 \var{timespec}, la cui definizione è riportata in +delle strutture di tipo \struct{timespec}, la cui definizione è riportata in \figref{fig:sys_timeval_struct}, che permettono di specificare un tempo con una precisione (teorica) fino al nanosecondo. @@ -1381,16 +1384,16 @@ conclusione di un processo 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 System V infatti se si imposta esplicitamente l'azione a \const{SIG\_IGN} il - segnale non viene generato ed il sistema non genera zombie (lo stato di - terminazione viene scartato senza dover chiamare una \func{wait}). L'azione - predefinita è sempre quella di ignorare il segnale, ma non attiva questo - comportamento. Linux, come BSD e POSIX, non supporta questa semantica ed usa - il nome di \const{SIGCLD} come sinonimo di \const{SIGCHLD}.} In generale -dunque, quando non interessa elaborare lo stato di uscita di un processo, si -può completare la gestione della terminazione installando un 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. + segnale non viene generato ed il sistema non genera zombie\index{zombie} (lo + stato di terminazione viene scartato senza dover chiamare una \func{wait}). + L'azione predefinita è sempre quella di ignorare il segnale, ma non attiva + questo comportamento. Linux, come BSD e POSIX, non supporta questa semantica + ed usa il nome di \const{SIGCLD} come sinonimo di \const{SIGCHLD}.} In +generale dunque, quando non interessa elaborare lo stato di uscita di un +processo, si può completare la gestione della terminazione installando un +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 implementazione generica di una routine di gestione per \const{SIGCHLD}, (che @@ -1398,7 +1401,7 @@ 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 \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. +di zombie\index{zombie}. % è pertanto % naturale usare un esempio che ci permette di concludere la trattazione della @@ -1406,16 +1409,9 @@ di zombie. % In questo caso si è tratterà di illustrare un esempio relativo ad un % gestore per che è previsto ritornare, - \begin{figure}[!htb] \footnotesize \begin{lstlisting}{} -#include /* error symbol definitions */ -#include /* signal handling declarations */ -#include -#include -#include "macro.h" - void HandSigCHLD(int sig) { int errno_save; @@ -1471,7 +1467,7 @@ rimosso sar Allora, nel caso della terminazione dei processi figli, se si chiamasse \func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un solo processo, anche se i processi terminati sono più di uno, e gli altri -resterebbero in stato di zombie per un tempo indefinito. +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 @@ -1559,8 +1555,8 @@ processo viene interrotto fra la chiamata di \func{alarm} e \func{pause} pu capitare (ad esempio se il sistema è molto carico) che il tempo di attesa scada prima dell'esecuzione quest'ultima, cosicché essa sarebbe eseguita dopo l'arrivo di \const{SIGALRM}. In questo caso ci si troverebbe di fronte ad un -deadlock, in quanto \func{pause} non verrebbe mai più interrotta (se non in -caso di un altro segnale). +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 @@ -1779,10 +1775,10 @@ corrente viene restituito indietro. Questo permette (specificando \param{act} nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal}, che non consente di ottenere l'azione corrente senza installarne una nuova. -Entrambi i puntatori fanno riferimento alla struttura \var{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 +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 \var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere più usato. @@ -1801,7 +1797,7 @@ struct sigaction \end{lstlisting} \end{minipage} \normalsize - \caption{La struttura \var{sigaction}.} + \caption{La struttura \structd{sigaction}.} \label{fig:sig_sigaction} \end{figure} @@ -1857,7 +1853,7 @@ in \tabref{tab:sig_sa_flag}. \secref{sec:sig_specific_features}).\\ \hline \end{tabular} - \caption{Valori del campo \var{sa\_flag} della struttura \var{sigaction}.} + \caption{Valori del campo \var{sa\_flag} della struttura \struct{sigaction}.} \label{tab:sig_sa_flag} \end{table} @@ -1866,7 +1862,7 @@ permette\footnote{La possibilit 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 ottenere alcune informazioni addizionali usando \var{sa\_handler} con un - secondo parametro addizionale di tipo \var{struct sigcontext}, che adesso è + secondo parametro addizionale di tipo \var{sigcontext}, che adesso è deprecato.} di utilizzare due forme diverse di gestore, da specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO}, rispettivamente attraverso i campi \var{sa\_sigaction} o \var{sa\_handler}, @@ -1874,7 +1870,7 @@ rispettivamente attraverso i campi \var{sa\_sigaction} o \var{sa\_handler}, questi vengono addirittura definiti come \ctyp{union}): la prima è quella classica usata anche con \func{signal}, la seconda permette invece di usare un gestore in grado di ricevere informazioni più dettagliate dal sistema, -attraverso la struttura \type{siginfo\_t}, riportata in +attraverso la struttura \struct{siginfo\_t}, riportata in \figref{fig:sig_siginfo_t}. \begin{figure}[!htb] @@ -1900,7 +1896,7 @@ siginfo_t { \end{lstlisting} \end{minipage} \normalsize - \caption{La struttura \type{siginfo\_t}.} + \caption{La struttura \structd{siginfo\_t}.} \label{fig:sig_siginfo_t} \end{figure} @@ -1934,14 +1930,14 @@ 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}) avvalora \var{si\_fd} con il numero del file descriptor e \var{si\_band} per i -dati urgenti su un socket. +dati urgenti su un socket\index{socket}. Benché sia possibile usare nello stesso programma sia \func{sigaction} che \func{signal} occorre molta attenzione, in quanto le due funzioni possono interagire in maniera anomala. Infatti l'azione specificata con -\var{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 +\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 precedentemente installato con \func{sigaction}, non sarà possibile effettuare un ripristino corretto dello stesso. @@ -1960,17 +1956,15 @@ typedef void SigFunc(int); inline SigFunc * Signal(int signo, SigFunc *func) { struct sigaction new_handl, old_handl; - new_handl.sa_handler=func; + new_handl.sa_handler = func; /* clear signal mask: no signal blocked during execution of func */ - if (sigemptyset(&new_handl.sa_mask)!=0){ /* initialize signal set */ - perror("cannot initializes the signal set to empty"); /* see mess. */ - exit(1); + if (sigemptyset(&new_handl.sa_mask)!=0){ /* initialize signal set */ + return SIG_ERR; } - new_handl.sa_flags=0; /* init to 0 all flags */ + new_handl.sa_flags=0; /* init to 0 all flags */ /* change action for signo signal */ - if (sigaction(signo,&new_handl,&old_handl)){ - perror("sigaction failed on signal action setting"); - exit(1); + if (sigaction(signo, &new_handl, &old_handl)){ + return SIG_ERR; } return (old_handl.sa_handler); } @@ -1982,10 +1976,29 @@ inline SigFunc * Signal(int signo, SigFunc *func) \end{figure} Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata -che abbia le stesse caratteristiche di \func{signal}, a definire una funzione -equivalente attraverso \func{sigaction}; la funzione è \code{Signal}, e si -trova definita nel file \file{SigHand.c} (nei sorgenti allegati), e riportata -in \figref{fig:sig_Signal_code}. La riutilizzeremo spesso in seguito. +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 +\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 + cui essa fa riferimento in maniera speciale inserendo il codice direttamente + nel testo del programma. Anche se i compilatori più moderni sono in grado + di effettuare da soli queste manipolazioni (impostando le opportune + ottimizzazioni) questa è una tecnica usata per migliorare le prestazioni per + le funzioni piccole ed usate di frequente (in particolare nel kernel, dove + in certi casi le ottimizzazioni dal compilatore, tarate per l'uso in user + space, non sono sempre adatte). In tal caso infatti le istruzioni per creare + un nuovo frame nello stack per chiamare la funzione costituirebbero una + parte rilevante 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.} + + + + \subsection{La gestione della \textsl{maschera dei segnali} o \textit{signal mask}} @@ -1996,12 +2009,12 @@ 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 \var{task\_struct} del + 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 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 \var{sigaction}. +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 @@ -2169,8 +2182,9 @@ segnale, i passi sono sempre i seguenti: \item Ripristinare la maschera dei segnali originaria. \end{enumerate*} Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi -riabilitarla immediatamente dopo, in questo modo si evita il deadlock dovuto -all'arrivo del segnale prima dell'esecuzione di \func{sigsuspend}. +riabilitarla immediatamente dopo, in questo modo si evita il +deadlock\index{deadlock} dovuto all'arrivo del segnale prima dell'esecuzione +di \func{sigsuspend}. \subsection{Ulteriori funzioni di gestione} @@ -2265,11 +2279,11 @@ typedef struct { \end{lstlisting} \end{minipage} \normalsize - \caption{La struttura \var{stack\_t}.} + \caption{La struttura \structd{stack\_t}.} \label{fig:sig_stack_t} \end{figure} -Il campo \var{ss\_sp} di \var{stack\_t} indica l'indirizzo base dello stack, +Il campo \var{ss\_sp} di \struct{stack\_t} indica l'indirizzo base dello stack, mentre \var{ss\_size} ne indica la dimensione; il campo \var{ss\_flags} invece indica lo stato dello stack. Nell'indicare un nuovo stack occorre inizializzare \var{ss\_sp} e \var{ss\_size} rispettivamente al puntatore e @@ -2313,16 +2327,16 @@ caratteristiche si sono abilitate con le macro viste in \secref{sec:intro_gcc_glibc_std}. Lo standard POSIX però prevede anche la presenza di altre due funzioni -\func{sigsetjmp} e \func{siglongjmp}, che permettono di decidere quale dei due -comportamenti il programma deve assumere; i loro prototipi sono: +\funcd{sigsetjmp} e \funcd{siglongjmp}, che permettono di decidere quale dei +due comportamenti il programma deve assumere; i loro prototipi sono: \begin{functions} \headdecl{setjmp.h} \funcdecl{int sigsetjmp(sigjmp\_buf env, int savesigs)} Salva il contesto - dello stack per un salto non locale. + dello stack per un salto non-locale\index{salto non-locale}. - \funcdecl{void siglongjmp(sigjmp\_buf env, int val)} Esegue un salto non - locale su un precedente contesto. + \funcdecl{void siglongjmp(sigjmp\_buf env, int val)} Esegue un salto + 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 @@ -2330,10 +2344,11 @@ comportamenti il programma deve assumere; i loro prototipi sono: \end{functions} Le due funzioni prendono come primo argomento la variabile su cui viene -salvato il contesto dello stack per permettere il 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 maschera dei segnali. +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 +maschera dei segnali. Nel caso di \func{sigsetjmp} se si specifica un valore di \param{savesigs} diverso da zero la maschera dei valori sarà salvata in \param{env} e @@ -2386,7 +2401,7 @@ vengono chiamati \textsl{segnali real-time}, in particolare: con un numero minore, che pertanto hanno una priorità maggiore. \item è stata introdotta la possibilità di restituire dei dati al gestore, attraverso l'uso di un campo apposito nella struttura - \type{siginfo\_t} accessibile tramite gestori di tipo + \struct{siginfo\_t} accessibile tramite gestori di tipo \var{sa\_sigaction}. \end{itemize*} @@ -2409,9 +2424,9 @@ real-time. Si tenga presente che questi nuovi segnali non sono associati a nessun evento sepcifico (a meno di non utilizzarli, come vedremo in \secref{sec:file_asyncronous_io}, per l'I/O asincrono) e devono essere inviati -esplicitamente. Tutti i segnali real-time restituiscono al gestore, oltre -ai campi \var{si\_pid} e \var{si\_uid} di \type{siginfo\_t} una struttura -\type{sigval} (riportata in \figref{fig:sig_sigval}) in cui può essere +esplicitamente. Tutti i segnali real-time restituiscono al gestore, oltre ai +campi \var{si\_pid} e \var{si\_uid} di \struct{siginfo\_t} una struttura +\struct{sigval} (riportata in \figref{fig:sig_sigval}) in cui può essere restituito al processo un valore o un indirizzo, che costituisce il meccanismo con cui il segnale è in grado di inviare una ulteriore informazione al processo. @@ -2427,15 +2442,15 @@ union sigval { \end{lstlisting} \end{minipage} \normalsize - \caption{La struttura \type{sigval}, usata dai segnali real time per + \caption{La struttura \structd{sigval}, usata dai segnali real time per restituire dati al gestore.} \label{fig:sig_sigval} \end{figure} A causa di queste loro caratteristiche, la funzione \func{kill} non è adatta ad inviare un segnale real time, in quanto non è in grado di fornire alcun -valore per \var{sigval}; per questo motivo lo standard ha previsto una nuova -funzione, \func{sigqueue}, il cui prototipo è: +valore per \struct{sigval}; per questo motivo lo standard ha previsto una +nuova funzione, \func{sigqueue}, il cui prototipo è: \begin{prototype}{signal.h} {int sigqueue(pid\_t pid, int signo, const union sigval value)} @@ -2462,17 +2477,17 @@ stessi; un valore nullo di \func{signo} permette di verificare le condizioni di errore senza inviare nessun segnale. Se il segnale è bloccato la funzione ritorna immediatamente, se si è -installato un gestore con \const{SA\_SIGINFO} e ci sono risorse -disponibili, vale a dire che c'è posto nella coda\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 +installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili, +vale a dire che c'è posto nella coda\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, \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32.}, esso viene inserito e diventa pendente; una volta consegnato riporterà nel campo \var{si\_code} di -\var{siginfo} il valore \const{SI\_QUEUE} e il campo \var{si\_value} riceverà -quanto inviato con \param{value}. Se invece si è installato un gestore -nella forma classica il segnale sarà generato, ma tutte le caratteristiche -tipiche dei segnali real-time (priorità e coda) saranno perse. +\struct{siginfo} il valore \const{SI\_QUEUE} e il campo \var{si\_value} +riceverà quanto inviato con \param{value}. Se invece si è installato un +gestore nella forma classica il segnale sarà generato, ma tutte le +caratteristiche tipiche dei segnali real-time (priorità e coda) saranno perse. Lo standard POSIX.1b definisce inoltre delle nuove funzioni che permettono di gestire l'attesa di segnali specifici su una coda, esse servono in particolar