X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=3adaee33b9f00e05307f202e53e70a206cf49a1d;hp=1288d6c95b6168cee4c0da69afe6d85120b97454;hb=9a6d19e384fe9b1afbe4d9124ac34eaf7aa57562;hpb=39d4e8cf8eb39ad46335bc6a04695367302034f8 diff --git a/signal.tex b/signal.tex index 1288d6c..3adaee3 100644 --- a/signal.tex +++ b/signal.tex @@ -279,7 +279,7 @@ di identificarli, e le funzioni che ne stampano la descrizione. Ciascun segnale è identificato rispetto al sistema da un numero, ma l'uso diretto di questo numero da parte dei programmi è da evitare, in quanto esso -può variare a seconda dell'implementazione del sistema, e nel caso si Linux, +può variare a seconda dell'implementazione del sistema, e nel caso di Linux, anche a seconda dell'architettura hardware. Per questo motivo ad ogni segnale viene associato un nome, definendo con una macro di preprocessore una costante uguale al suddetto numero. Sono questi @@ -512,8 +512,8 @@ segnali sono: interruzione per il programma. È quello che viene generato di default dal comando \cmd{kill} o dall'invio sul terminale del carattere di controllo INTR (interrupt, generato dalla sequenza \cmd{C-c}). -\item[\const{SIGQUIT}] È analogo a \const{SIGINT} con la differenze che è - controllato da un'altro carattere di controllo, QUIT, corrispondente alla +\item[\const{SIGQUIT}] È analogo a \const{SIGINT} con la differenza che è + controllato da un altro carattere di controllo, QUIT, corrispondente alla sequenza \verb|C-\|. A differenza del precedente l'azione predefinita, oltre alla terminazione del processo, comporta anche la creazione di un core dump. @@ -890,9 +890,9 @@ Il numero di segnale passato in \param{signum} pu 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 +\const{SIG\_IGN} con cui si dice di ignorare il segnale e \const{SIG\_DFL} per reinstallare l'azione predefinita.\footnote{si ricordi però che i due segnali - \const{SIGKILL} e \const{SIGSTOP} non possono essere ignorati né + \const{SIGKILL} e \const{SIGSTOP} non possono essere né ignorati né intercettati; l'uso di \const{SIG\_IGN} per questi segnali non ha alcun effetto.} @@ -1076,10 +1076,9 @@ segnale; siccome alla chiamata viene cancellato ogni precedente allarme, questo può essere usato per cancellare una programmazione precedente. La funzione inoltre ritorna il numero di secondi rimanenti all'invio -dell'allarme precedentemente programmato, in modo che sia possibile -controllare se non si cancella un precedente allarme ed eventualmente -predisporre le opportune misure per gestire il caso di necessità di più -interruzioni. +dell'allarme programmato in precedenza. In questo modo è possibile controllare +se non si è cancellato un precedente allarme e predisporre eventuali misure +che permettano di gestire il caso in cui servono più interruzioni. 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 @@ -1113,7 +1112,7 @@ suo prototipo itimerval *value, struct itimerval *ovalue)} Predispone l'invio di un segnale di allarme alla scadenza dell'intervallo - \param{value} sul timer specificato da \func{which}. + \param{value} sul timer specificato da \param{which}. \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di errore, nel qual caso \var{errno} assumerà uno dei valori \errval{EINVAL} o @@ -1209,7 +1208,7 @@ valore corrente di un timer senza modificarlo, \begin{prototype}{sys/time.h}{int getitimer(int which, struct itimerval *value)} - Legge in \param{value} il valore del timer specificato da \func{which}. + Legge in \param{value} il valore del timer specificato da \param{which}. \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di errore e restituisce gli stessi errori di \func{getitimer}} @@ -1241,7 +1240,7 @@ il processo non viene terminato direttamente dal gestore sia la stessa \func{abort} a farlo al ritorno dello stesso. Inoltre, sempre seguendo lo standard POSIX, prima della terminazione tutti i file aperti e gli stream saranno chiusi ed i buffer scaricati su disco. Non verranno invece eseguite le -eventuali funzioni registrate con \func{at\_exit} e \func{on\_exit}. +eventuali funzioni registrate con \func{atexit} e \func{on\_exit}. \subsection{Le funzioni di pausa e attesa} @@ -1363,7 +1362,7 @@ valore restituito in \param{rem} di 1/\const{HZ}. In realtà è possibile ottenere anche pause più precise del centesimo di -secondo usando politiche di scheduling real time come \const{SCHED\_FIFO} o +secondo usando politiche di scheduling real-time come \const{SCHED\_FIFO} o \const{SCHED\_RR}; in tal caso infatti il meccanismo di scheduling ordinario viene evitato, e si raggiungono pause fino ai 2~ms con precisioni del $\mu$s. @@ -1398,12 +1397,6 @@ di sez.~\ref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione di zombie\index{zombie}. -% è pertanto -% naturale usare un esempio che ci permette di concludere la trattazione della -% terminazione dei processi. -% In questo caso si è tratterà di illustrare un esempio relativo ad un -% gestore per che è previsto ritornare, - \begin{figure}[!htb] \footnotesize \centering \begin{minipage}[c]{15cm} @@ -1411,7 +1404,7 @@ di zombie\index{zombie}. \end{minipage} \normalsize \caption{Codice di una funzione generica di gestione per il segnale - \texttt{SIGCHLD}.} + \texttt{SIGCHLD}.} \label{fig:sig_sigchld_handl} \end{figure} @@ -1421,7 +1414,7 @@ comincia (\texttt{\small 6--7}) con il salvare lo stato corrente di \var{errno}, in modo da poterlo ripristinare prima del ritorno del gestore (\texttt{\small 16--17}). In questo modo si preserva il valore della variabile visto dal corso di esecuzione principale del processo, che altrimenti sarebbe -sovrascritto dal valore restituito nella successiva chiamata di \func{wait}. +sovrascritto dal valore restituito nella successiva chiamata di \func{waitpid}. Il compito principale del gestore è quello di ricevere lo stato di terminazione del processo, cosa che viene eseguita nel ciclo in @@ -1437,7 +1430,7 @@ Questo pu che molti processi figli terminino in rapida successione. Esso inoltre si presenta tutte le volte che un segnale viene bloccato: per quanti siano i segnali emessi durante il periodo di blocco, una volta che quest'ultimo sarà -rimosso sarà recapitato un solo segnale. +rimosso verrà recapitato un solo segnale. Allora, nel caso della terminazione dei processi figli, se si chiamasse \func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un @@ -1502,9 +1495,9 @@ l'interruzione di \func{pause} venisse causata da un altro segnale. Questo codice però, a parte il non gestire il caso in cui si è avuta una precedente chiamata a \func{alarm} (che si è tralasciato per brevità), presenta una pericolosa race condition\index{\textit{race~condition}}. -Infatti se il 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 +Infatti, se il 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 di quest'ultima, cosicché essa sarebbe eseguita dopo l'arrivo di \const{SIGALRM}. In questo caso ci si troverebbe di fronte ad un deadlock\index{\textit{deadlock}}, in quanto \func{pause} non verrebbe mai più interrotta (se non in caso di un altro @@ -1526,8 +1519,8 @@ codice del tipo di quello riportato in fig.~\ref{fig:sig_sleep_incomplete}. \label{fig:sig_sleep_incomplete} \end{figure} -In questo caso il gestore (\texttt{\small 18-26}) non ritorna come in -fig.~\ref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 24}) per +In questo caso il gestore (\texttt{\small 18-27}) non ritorna come in +fig.~\ref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 25}) 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 @@ -1564,10 +1557,12 @@ quale potr segnale, e prendere le relative azioni conseguenti (\texttt{\small 6-11}). Questo è il tipico esempio di caso, già citato in -sez.~\ref{sec:proc_race_cond}, in cui si genera una race condition -\index{\textit{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. +sez.~\ref{sec:proc_race_cond}, in cui si genera una +\index{\textit{race~condition}}race condition; infatti, in una situazione in +cui un segnale è già arrivato (e \var{flag} è già ad 1) se un altro segnale +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 @@ -1580,30 +1575,29 @@ reagire alla ricezione di un segnale. \subsection{Gli \textsl{insiemi di segnali} o \textit{signal set}} \label{sec:sig_sigset} -\index{\textit{signal~set}|(} +\index{\textit{signal~set}|(} Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali originarie, nate con la semantica inaffidabile, hanno dei limiti non superabili; in particolare non è prevista nessuna funzione che permetta di -gestire gestire il blocco dei segnali o di verificare lo stato dei segnali -pendenti. Per questo motivo lo standard POSIX.1, insieme alla nuova semantica -dei segnali ha introdotto una interfaccia di gestione completamente nuova, che -permette di ottenete un controllo molto più dettagliato. In particolare lo +gestire il blocco dei segnali o di verificare lo stato dei segnali pendenti. +Per questo motivo lo standard POSIX.1, insieme alla nuova semantica dei +segnali ha introdotto una interfaccia di gestione completamente nuova, che +permette di ottenere un controllo molto più dettagliato. In particolare lo standard ha introdotto un nuovo tipo di dato \type{sigset\_t}, che permette di rappresentare un \textsl{insieme di segnali} (un \textit{signal set}, come -viene usualmente chiamato), che è il tipo di dato che viene usato per gestire -il blocco dei segnali. +viene usualmente chiamato), tale tipo di dato viene usato per gestire il +blocco dei segnali. In genere un \textsl{insieme di segnali} è rappresentato da un intero di -dimensione opportuna, di solito si pari al numero di bit dell'architettura -della macchina\footnote{nel caso dei PC questo comporta un massimo di 32 - segnali distinti, dato che in Linux questi sono sufficienti non c'è - necessità di nessuna struttura più complicata.}, ciascun bit del quale è -associato ad uno specifico segnale; in questo modo è di solito possibile -implementare le operazioni direttamente con istruzioni elementari del -processore; lo standard POSIX.1 definisce cinque funzioni per la manipolazione -degli insiemi di segnali: \funcd{sigemptyset}, \funcd{sigfillset}, -\funcd{sigaddset}, \funcd{sigdelset} e \funcd{sigismember}, i cui prototipi -sono: +dimensione opportuna, di solito pari al numero di bit dell'architettura della +macchina,\footnote{nel caso dei PC questo comporta un massimo di 32 segnali + distinti: dato che in Linux questi sono sufficienti non c'è necessità di + nessuna struttura più complicata.} ciascun bit del quale è associato ad uno +specifico segnale; in questo modo è di solito possibile implementare le +operazioni direttamente con istruzioni elementari del processore. Lo standard +POSIX.1 definisce cinque funzioni per la manipolazione degli insiemi di +segnali: \funcd{sigemptyset}, \funcd{sigfillset}, \funcd{sigaddset}, +\funcd{sigdelset} e \funcd{sigismember}, i cui prototipi sono: \begin{functions} \headdecl{signal.h} @@ -1656,7 +1650,7 @@ POSIX.1 ha ridefinito completamente l'interfaccia per la gestione dei segnali, rendendola molto più flessibile e robusta, anche se leggermente più complessa. La funzione principale dell'interfaccia POSIX.1 per i segnali è -\funcd{sigaction}. Essa ha sostanzialemente lo stesso uso di \func{signal}, +\funcd{sigaction}. Essa ha sostanzialmente lo stesso uso di \func{signal}, permette cioè di specificare le modalità con cui un segnale può essere gestito da un processo. Il suo prototipo è: \begin{prototype}{signal.h}{int sigaction(int signum, const struct sigaction @@ -1816,10 +1810,11 @@ eventualmente presenti dipendono dal segnale, cos 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 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}. +\const{SIGSEGV} e \const{SIGBUS} avvalorano \var{si\_addr} con l'indirizzo in +cui è 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}. Benché sia possibile usare nello stesso programma sia \func{sigaction} che \func{signal} occorre molta attenzione, in quanto le due funzioni possono @@ -1844,7 +1839,7 @@ sempre il caso di evitare l'uso di \func{signal} a favore di \func{sigaction}. \includecodesample{listati/Signal.c} \end{minipage} \normalsize - \caption{La funzione \funcd{Signal}, equivalente a \func{signal}, definita + \caption{La funzione \func{Signal}, equivalente a \func{signal}, definita attraverso \func{sigaction}.} \label{fig:sig_Signal_code} \end{figure} @@ -1872,15 +1867,13 @@ estremamente semplice, - - \subsection{La gestione della \textsl{maschera dei segnali} o \textit{signal mask}} \label{sec:sig_sigmask} \index{\textit{signal mask}|(} Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like -permettono si bloccare temporaneamente (o di eliminare completamente, +permettono di 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 @@ -1895,7 +1888,7 @@ 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. +che essi siano eseguite senza interruzioni. Le operazioni più semplici, come l'assegnazione o il controllo di una variabile (per essere sicuri si può usare il tipo \type{sig\_atomic\_t}) di @@ -2000,18 +1993,18 @@ presenta neanche questa necessit Per evitare i problemi di interferenza con gli altri segnali in questo caso 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}) +l'uso di \func{longjmp}. Come in precedenza il gestore (\texttt{\small 27-30}) non esegue nessuna operazione, limitandosi a ritornare per interrompere il programma messo in attesa. -La prima parte della funzione (\texttt{\small 11-15}) provvede ad installare +La prima parte della funzione (\texttt{\small 6-10}) provvede ad installare l'opportuno gestore per \const{SIGALRM}, salvando quello originario, che -sarà ripristinato alla conclusione della stessa (\texttt{\small 28}); il passo -successivo è quello di bloccare \const{SIGALRM} (\texttt{\small 17-19}) per +sarà ripristinato alla conclusione della stessa (\texttt{\small 23}); il passo +successivo è quello di bloccare \const{SIGALRM} (\texttt{\small 11-14}) per evitare che esso possa essere ricevuto dal processo fra l'esecuzione di -\func{alarm} (\texttt{\small 21}) e la sospensione dello stesso. Nel fare +\func{alarm} (\texttt{\small 16}) e la sospensione dello stesso. Nel fare questo si salva la maschera corrente dei segnali, che sarà ripristinata alla -fine (\texttt{\small 27}), e al contempo si prepara la maschera dei segnali +fine (\texttt{\small 22}), e al contempo si prepara la maschera dei segnali \var{sleep\_mask} per riattivare \const{SIGALRM} all'esecuzione di \func{sigsuspend}. @@ -2023,9 +2016,9 @@ altra situazione in cui si deve attendere per un segnale, i passi sono sempre i seguenti: \begin{enumerate*} \item Leggere la maschera dei segnali corrente e bloccare il segnale voluto - con \func{sigprocmask}. + con \func{sigprocmask}; \item Mandare il processo in attesa con \func{sigsuspend} abilitando la - ricezione del segnale voluto. + ricezione del segnale voluto; \item Ripristinare la maschera dei segnali originaria. \end{enumerate*} Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi @@ -2054,7 +2047,7 @@ Scrive in \param{set} l'insieme dei segnali pendenti. \end{prototype} La funzione permette di ricavare quali sono i segnali pendenti per il processo -in corso, cioè i segnali che sono stato inviati dal kernel ma non sono stati +in corso, cioè i segnali che sono stati inviati dal kernel ma non sono stati ancora ricevuti dal processo in quanto bloccati. Non esiste una funzione equivalente nella vecchia interfaccia, ma essa è tutto sommato poco utile, dato che essa può solo assicurare che un segnale è stato inviato, dato che @@ -2069,9 +2062,9 @@ gestore. L'uso di uno stack alternativo gestori, occorre però seguire una certa procedura: \begin{enumerate} \item Allocare un'area di memoria di dimensione sufficiente da usare come - stack alternativo. + stack alternativo; \item Usare la funzione \func{sigaltstack} per rendere noto al sistema - l'esistenza e la locazione dello stack alternativo. + 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 tab.~\ref{tab:sig_sa_flag}) per dire al sistema di usare lo stack alternativo durante l'esecuzione del @@ -2091,7 +2084,7 @@ maggiore di questo valore. Quando si conosce esattamente quanto necessario al gestore gli si può aggiungere questo valore per allocare uno stack di dimensione sufficiente. -Come accennato per poter essere usato lo stack per i segnali deve essere +Come accennato, per poter essere usato, lo stack per i segnali deve essere indicato al sistema attraverso la funzione \funcd{sigaltstack}; il suo prototipo è: \begin{prototype}{signal.h} @@ -2146,7 +2139,7 @@ sullo stack alternativo (nel qual caso non In genere si installa uno stack alternativo per i segnali quando si teme di avere problemi di esaurimento dello stack standard o di superamento di un -limite imposto con chiamata de tipo \code{setrlimit(RLIMIT\_STACK, \&rlim)}. +limite imposto con chiamate del tipo \code{setrlimit(RLIMIT\_STACK, \&rlim)}. In tal caso infatti si avrebbe un segnale di \const{SIGSEGV}, che potrebbe essere gestito soltanto avendo abilitato uno stack alternativo. @@ -2192,13 +2185,13 @@ due 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 -\index{salto~non-locale}; nel caso specifico essa è di tipo +salvato il contesto dello stack per permettere il +\index{salto~non-locale}salto non-locale; nel caso specifico essa è di tipo \type{sigjmp\_buf}, e non \type{jmp\_buf} come per le analoghe di 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} +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 ripristinata in un successivo \func{siglongjmp}; quest'ultima funzione, a parte l'uso di \type{sigjmp\_buf} per \param{env}, è assolutamente identica a @@ -2220,11 +2213,11 @@ segnali classici: \item[I segnali non sono accumulati] se più segnali vengono generati prima dell'esecuzione di un gestore 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. + accorgersi di quante volte l'evento che ha generato il segnale è accaduto; \item[I segnali non trasportano informazione] 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). + l'informazione che il kernel associa ad un segnale è il suo numero); \item[I segnali non hanno un ordine di consegna] l'ordine in cui diversi segnali vengono consegnati è casuale e non prevedibile. Non è possibile stabilire una priorità per cui la reazione a @@ -2255,10 +2248,10 @@ Queste nuove funzionalit disponibile anche con i segnali ordinari) si applicano solo ai nuovi segnali real-time; questi ultimi sono accessibili in un range di valori specificati dalle due macro \const{SIGRTMIN} e \const{SIGRTMAX},\footnote{in Linux di - solito il primo valore è 32, ed il secondo \code{\_NSIG-1}, che di norma è - 63, per un totale di 32 segnali disponibili, contro gli almeno 8 richiesti - da POSIX.1b.} che specificano il numero minimo e massimo associato ad un -segnale real-time. + solito (cioè sulla piattaforma i386) il primo valore è 33, ed il secondo + \code{\_NSIG-1}, che di norma è 64, per un totale di 32 segnali disponibili, + contro gli almeno 8 richiesti da POSIX.1b.} che specificano il numero minimo +e massimo associato ad un segnale real-time. I segnali con un numero più basso hanno una priorità maggiore e vengono consegnati per primi, inoltre i segnali real-time non possono interrompere @@ -2279,7 +2272,7 @@ gestori devono essere installati con \func{sigaction}, specificando per 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 +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 real-time sono \var{si\_pid} e @@ -2309,7 +2302,7 @@ alcune definizioni essa viene identificata anche come \code{union sigval}. \end{figure} A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad -inviare segnali real-time, poichè non è in grado di fornire alcun valore +inviare segnali real-time, poiché non è in grado di fornire alcun valore per \struct{sigval\_t}; per questo motivo lo standard ha previsto una nuova funzione, \funcd{sigqueue}, il cui prototipo è: \begin{prototype}{signal.h} @@ -2334,7 +2327,7 @@ funzione, \funcd{sigqueue}, il cui prototipo Il comportamento della funzione è analogo a quello di \func{kill}, ed i privilegi occorrenti ad inviare il segnale ad un determinato processo sono gli -stessi; un valore nullo di \func{signo} permette di verificare le condizioni +stessi; un valore nullo di \param{signo} permette di verificare le condizioni di errore senza inviare nessun segnale. Se il segnale è bloccato la funzione ritorna immediatamente, se si è