Questa è la ragione per cui l'implementazione dei segnali secondo 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 \itindex{race~condition} \textit{race condition}
-(si ricordi 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 segnale, ma non è possibile
-istruire il sistema a non fare nulla in occasione di un segnale, pur
-mantenendo memoria del fatto che è avvenuto.
+sono sempre possibili delle \textit{race condition} (si ricordi
+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 segnale, ma non è possibile istruire il sistema a
+non fare nulla in occasione di un segnale, pur mantenendo memoria del fatto
+che è avvenuto.
Nella semantica \textsl{affidabile} (quella utilizzata da Linux e da ogni Unix
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 un apposito campo della
-\struct{task\_struct} del processo nella \itindex{process~table}
-\textit{process table} (si veda fig.~\ref{fig:proc_task_struct}).
+\struct{task\_struct} del processo nella \textit{process table} (si veda
+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
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 alla
-radice possibili \itindex{race~condition} \textit{race condition}.
+radice possibili \textit{race condition}.
Nel caso non sia stata specificata un'azione, viene utilizzata la cosiddetta
azione predefinita che, come vedremo in sez.~\ref{sec:sig_standard}, è propria
\signal{SIGILL} &PA& C & Istruzione illecita.\\
\signal{SIGTRAP} &S & C & Trappole per un Trace/breakpoint.\\
\signal{SIGABRT} &PA& C & Segnale di abort da \func{abort}.\\
- \signal{SIGIOT} &B & C & Trappola di I/O. Sinonimo di \signal{SIGABRT}.\\
+ \signald{SIGIOT} &B & C & Trappola di I/O. Sinonimo di \signal{SIGABRT}.\\
\signal{SIGBUS} &BS& C & Errore sul bus (bad memory access).\\
\signal{SIGFPE} &AP& C & Errore aritmetico.\\
\signal{SIGKILL} &P & T& Segnale di terminazione forzata.\\
\signal{SIGUSR1} &P & T & Segnale utente numero 1.\\
\signal{SIGSEGV} &AP& C & Errore di accesso in memoria.\\
\signal{SIGUSR2} &P & T & Segnale utente numero 2.\\
- \signal{SIGPIPE} &P & T & Pipe spezzata.\\
+ \signal{SIGPIPE} &P & T & \textit{Pipe} spezzata.\\
\signal{SIGALRM} &P & T & Segnale del timer da \func{alarm}.\\
\signal{SIGTERM} &AP& T & Segnale di terminazione (\texttt{C-\bslash}).\\
\signal{SIGCHLD} &P & I & Figlio terminato o fermato.\\
\signal{SIGSYS} &VS& C & \textit{system call} sbagliata.\\
\hline
\signal{SIGSTKFLT}&?& T & Errore sullo stack del coprocessore (inusato).\\
- \signal{SIGUNUSED}&?& C & Segnale inutilizzato (sinonimo di
+ \signald{SIGUNUSED}&?& C & Segnale inutilizzato (sinonimo di
\signal{SIGSYS}).\\
\hline
\signal{SIGCLD} &V & I & Sinonimo di \signal{SIGCHLD}.\\
\label{sec:sig_prog_error}
Questi segnali sono generati quando il sistema, o in certi casi direttamente
-l'hardware (come per i \itindex{page~fault} \textit{page fault} non validi o
-le eccezioni del processore) rileva un qualche errore insanabile nel programma
-in esecuzione. In generale la generazione di questi segnali significa che il
+l'hardware (come per i \textit{page fault} non validi o le eccezioni del
+processore) rileva un qualche errore insanabile nel programma in
+esecuzione. In generale la generazione di questi segnali significa che il
programma ha dei gravi problemi (ad esempio ha dereferenziato un puntatore non
valido o ha eseguito una operazione aritmetica proibita) e l'esecuzione non
può essere proseguita.
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 \index{file!di lock} 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 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
può usare per ricostruire lo stato del programma al momento della
terminazione. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\signal{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome
+\item[\signald{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome
derivi da \textit{floating point exception} si applica a tutti gli errori
aritmetici compresa la divisione per zero e l'overflow. Se il gestore
ritorna il comportamento del processo è indefinito, ed ignorare questo
% aritmetiche e richiede che esse siano notificate.
% TODO trovare altre info su SIGFPE e trattare la notifica delle eccezioni
-\item[\signal{SIGILL}] Il nome deriva da \textit{illegal instruction},
+\item[\signald{SIGILL}] Il nome deriva da \textit{illegal instruction},
significa che il programma sta cercando di eseguire una istruzione
privilegiata o inesistente, in generale del codice illecito. Poiché il
compilatore del C genera del codice valido si ottiene questo segnale se il
file eseguibile è corrotto o si stanno cercando di eseguire dei dati.
Quest'ultimo caso può accadere quando si passa un puntatore sbagliato al
posto di un puntatore a funzione, o si eccede la scrittura di un vettore di
- una variabile locale, andando a corrompere lo \itindex{stack}
- \textit{stack}. Lo stesso segnale viene generato in caso di overflow dello
- \itindex{stack} \textit{stack} o di problemi nell'esecuzione di un gestore.
- Se il gestore ritorna il comportamento del processo è indefinito.
-
-\item[\signal{SIGSEGV}] Il nome deriva da \itindex{segment~violation}
- \textit{segment violation}, e significa che il programma sta cercando di
- leggere o scrivere in una zona di memoria protetta al di fuori di quella che
- gli è stata riservata dal sistema. In genere è il meccanismo della
- protezione della memoria che si accorge dell'errore ed il kernel genera il
- segnale. È tipico ottenere questo segnale dereferenziando un puntatore
- nullo o non inizializzato leggendo al di là della fine di un vettore. Se il
- gestore ritorna il comportamento del processo è indefinito.
-
-\item[\signal{SIGBUS}] Il nome deriva da \textit{bus error}. Come
+ una variabile locale, andando a corrompere lo \textit{stack}. Lo stesso
+ segnale viene generato in caso di overflow dello \textit{stack} o di
+ problemi nell'esecuzione di un gestore. Se il gestore ritorna il
+ comportamento del processo è indefinito.
+
+\item[\signald{SIGSEGV}] Il nome deriva da \textit{segment violation}, e
+ significa che il programma sta cercando di leggere o scrivere in una zona di
+ memoria protetta al di fuori di quella che gli è stata riservata dal
+ sistema. In genere è il meccanismo della protezione della memoria che si
+ accorge dell'errore ed il kernel genera il segnale. È tipico ottenere
+ questo segnale dereferenziando un puntatore nullo o non inizializzato
+ leggendo al di là della fine di un vettore. Se il gestore ritorna il
+ comportamento del processo è indefinito.
+
+\item[\signald{SIGBUS}] Il nome deriva da \textit{bus error}. Come
\signal{SIGSEGV} questo è un segnale che viene generato di solito quando si
dereferenzia un puntatore non inizializzato, la differenza è che
\signal{SIGSEGV} indica un accesso non permesso su un indirizzo esistente
- (al di fuori dallo \itindex{heap} \textit{heap} o dallo \itindex{stack}
- \textit{stack}), mentre \signal{SIGBUS} indica l'accesso ad un indirizzo non
- valido, come nel caso di un puntatore non allineato.
+ (al di fuori dallo \textit{heap} o dallo \textit{stack}), mentre
+ \signal{SIGBUS} indica l'accesso ad un indirizzo non valido, come nel caso
+ di un puntatore non allineato.
-\item[\signal{SIGABRT}] Il nome deriva da \textit{abort}. Il segnale indica
+\item[\signald{SIGABRT}] Il nome deriva da \textit{abort}. Il segnale indica
che il programma stesso ha rilevato un errore che viene riportato chiamando
la funzione \func{abort}, che genera questo segnale.
-\item[\signal{SIGTRAP}] È il segnale generato da un'istruzione di breakpoint o
+\item[\signald{SIGTRAP}] È il segnale generato da un'istruzione di breakpoint o
dall'attivazione del tracciamento per il processo. È usato dai programmi per
il debugging e un programma normale non dovrebbe ricevere questo segnale.
-\item[\signal{SIGSYS}] Sta ad indicare che si è eseguita una istruzione che
+\item[\signald{SIGSYS}] Sta ad indicare che si è eseguita una istruzione che
richiede l'esecuzione di una \textit{system call}, ma si è fornito un codice
sbagliato per quest'ultima.
-\item[\signal{SIGEMT}] Il nome sta per \textit{emulation trap}. Il segnale non
+\item[\signald{SIGEMT}] Il nome sta per \textit{emulation trap}. Il segnale non
è previsto da nessuno standard ed è definito solo su alcune architetture che
come il vecchio PDP11 prevedono questo tipo di interruzione, non è presente
sui normali PC.
periferica). L'azione predefinita di questi segnali è di terminare il
processo, questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\signal{SIGTERM}] Il nome sta per \textit{terminate}. È un segnale
+\item[\signald{SIGTERM}] Il nome sta per \textit{terminate}. È un segnale
generico usato per causare la conclusione di un programma. È quello che
viene generato di default dal comando \cmd{kill}. Al contrario di
\signal{SIGKILL} può essere intercettato, ignorato, bloccato. In genere lo
si usa per chiedere in maniera ``\textsl{educata}'' ad un processo di
concludersi.
-\item[\signal{SIGINT}] Il nome sta per \textit{interrupt}. È il segnale di
+\item[\signald{SIGINT}] Il nome sta per \textit{interrupt}. È il segnale di
interruzione per il programma. È quello che viene generato di default dal
dall'invio sul terminale del carattere di controllo ``\textit{INTR}'',
\textit{interrupt} appunto, che viene generato normalmente dalla sequenza
\cmd{C-c} sulla tastiera.
-\item[\signal{SIGQUIT}] È analogo a \signal{SIGINT} con la differenza che è
+\item[\signald{SIGQUIT}] È analogo a \signal{SIGINT} con la differenza che è
controllato da un altro carattere di controllo, ``\textit{QUIT}'',
corrispondente alla sequenza \texttt{C-\bslash} sulla tastiera. A differenza
del precedente l'azione predefinita, oltre alla terminazione del processo,
(tipo la cancellazione di file temporanei), dato che in certi casi esse
possono eliminare informazioni utili nell'esame dei \textit{core dump}.
-\item[\signal{SIGKILL}] Il nome è utilizzato per terminare in maniera immediata
+\item[\signald{SIGKILL}] Il nome è utilizzato per terminare in maniera immediata
qualunque programma. Questo segnale non può essere né intercettato, né
ignorato, né bloccato, per cui causa comunque la terminazione del processo.
In genere esso viene generato solo per richiesta esplicita dell'utente dal
per condizioni particolari il processo non può più essere eseguito neanche
per eseguire un gestore.
-\item[\signal{SIGHUP}] Il nome sta per \textit{hang-up}. Segnala che il
+\item[\signald{SIGHUP}] Il nome sta per \textit{hang-up}. Segnala che il
terminale dell'utente si è disconnesso, ad esempio perché si è interrotta la
rete. Viene usato anche per riportare la terminazione del processo di
controllo di un terminale a tutti i processi della sessione (vedi
predefinita è irrilevante, in quanto il loro uso presuppone sempre la
necessità di un gestore. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\signal{SIGALRM}] Il nome sta per \textit{alarm}. Segnale la scadenza di
+\item[\signald{SIGALRM}] Il nome sta per \textit{alarm}. Segnale la scadenza di
un timer misurato sul tempo reale o sull'orologio di sistema. È normalmente
usato dalla funzione \func{alarm}.
-\item[\const{SIVGTALRM}] Il nome sta per \textit{virtual alarm}. È analogo al
+\item[\signald{SIVGTALRM}] Il nome sta per \textit{virtual alarm}. È analogo al
precedente ma segnala la scadenza di un timer sul tempo di CPU usato dal
processo.
-\item[\signal{SIGPROF}] Il nome sta per \textit{profiling}. Indica la scadenza
+\item[\signald{SIGPROF}] Il nome sta per \textit{profiling}. Indica la scadenza
di un timer che misura sia il tempo di CPU speso direttamente dal processo
che quello che il sistema ha speso per conto di quest'ultimo. In genere
viene usato dagli strumenti che servono a fare la profilazione dell'utilizzo
generare questi segnali. L'azione predefinita è di essere ignorati. Questi
segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\signal{SIGIO}] Questo segnale viene inviato quando un file descriptor è
+\item[\signald{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 chiamata a \func{fcntl} che lo attiva abbia
avuto successo.
-\item[\signal{SIGURG}] Questo segnale è inviato quando arrivano dei dati
+\item[\signald{SIGURG}] Questo segnale è inviato quando arrivano dei dati
urgenti o \itindex{out-of-band} \textit{out-of-band} su di un
socket; per maggiori dettagli al proposito si veda
sez.~\ref{sec:TCP_urgent_data}.
-\item[\signal{SIGPOLL}] Questo segnale è definito nella standard POSIX.1-2001,
+\item[\signald{SIGPOLL}] Questo segnale è definito nella standard POSIX.1-2001,
ed è equivalente a \signal{SIGIO} che invece deriva da BSD. Su Linux è
definito per compatibilità con i sistemi System V.
\end{basedescript}
loro uso è specializzato e viene trattato in maniera specifica nelle sezioni
in cui si trattano gli argomenti relativi. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\signal{SIGCHLD}] Questo è il segnale mandato al processo padre quando un
+\item[\signald{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 sez.~\ref{sec:proc_wait}.
-\item[\signal{SIGCLD}] Per Linux questo è solo un segnale identico al
+\item[\signald{SIGCLD}] Per Linux questo è solo un segnale identico al
precedente e definito come sinonimo. Il nome è obsoleto, deriva dalla
definizione del segnale su System V, ed oggi deve essere evitato.
-\item[\signal{SIGCONT}] Il nome sta per \textit{continue}. Il segnale viene
+\item[\signald{SIGCONT}] Il nome sta per \textit{continue}. Il segnale viene
usato per fare ripartire un programma precedentemente fermato da
\signal{SIGSTOP}. Questo segnale ha un comportamento speciale, e fa sempre
ripartire il processo prima della sua consegna. Il comportamento predefinito
se viene fermato e riavviato, come per esempio riscrivere un prompt, o
inviare un avviso.
-\item[\signal{SIGSTOP}] Il segnale ferma l'esecuzione di un processo, lo porta
+\item[\signald{SIGSTOP}] Il segnale ferma l'esecuzione di un processo, lo porta
cioè nello stato \textit{stopped} (vedi sez.~\ref{sec:proc_sched}). Il
segnale non può essere né intercettato, né ignorato, né bloccato.
-\item[\signal{SIGTSTP}] Il nome sta per \textit{interactive stop}. Il segnale
+\item[\signald{SIGTSTP}] Il nome sta per \textit{interactive stop}. Il segnale
ferma il processo interattivamente, ed è generato dal carattere
``\textit{SUSP}'', prodotto dalla combinazione di tasti \cmd{C-z}, ed al
contrario di \signal{SIGSTOP} può essere intercettato e ignorato. In genere
esempio un programma ha disabilitato l'eco sul terminale può installare un
gestore per riabilitarlo prima di fermarsi.
-\item[\signal{SIGTTIN}] Un processo non può leggere dal terminale se esegue
+\item[\signald{SIGTTIN}] Un processo non può leggere dal terminale se esegue
una sessione di lavoro in \textit{background}. Quando un processo in
\textit{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
sez.~\ref{sec:sess_job_control_overview}.
-\item[\signal{SIGTTOU}] Segnale analogo al precedente \signal{SIGTTIN}, ma
+\item[\signald{SIGTTOU}] Segnale analogo al precedente \signal{SIGTTIN}, ma
generato quando si tenta di scrivere sul terminale o modificarne uno dei
modi con un processo in \textit{background}. L'azione predefinita è di
fermare il processo, l'argomento è trattato in
resto del sistema. L'azione predefinita di questi segnali è normalmente
quella di terminare il processo, questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\signal{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
- 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}.
-
-\item[\signal{SIGXCPU}] Sta per \textit{CPU time limit exceeded}. Questo
+\item[\signald{SIGPIPE}] Sta per \textit{Broken pipe}. Se si usano delle
+ \textit{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 sez.~\ref{sec:ipc_pipes}). Se il processo in lettura non è
+ partito o è terminato inavvertitamente alla scrittura sulla \textit{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}.
+
+\item[\signald{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 sez.~\ref{sec:sys_resource_limit}. Fino al
kernel 2.2 terminava semplicemente il processo, a partire dal kernel 2.4,
seguendo le indicazioni dello standard POSIX.1-2001 viene anche generato un
\textit{core dump}.
-\item[\signal{SIGXFSZ}] Sta per \textit{File size limit exceeded}. Questo
+\item[\signald{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 sez.~\ref{sec:sys_resource_limit}. Fino al kernel 2.2 terminava
semplicemente il processo, a partire dal kernel 2.4, seguendo le indicazioni
dello standard POSIX.1-2001 viene anche generato un \textit{core dump}.
-\item[\signal{SIGLOST}] Sta per \textit{Resource lost}. Tradizionalmente è il
+\item[\signald{SIGLOST}] Sta per \textit{Resource lost}. Tradizionalmente è il
segnale che viene generato quando si perde un advisory lock su un file su
NFS perché il server NFS è stato riavviato. Il progetto GNU lo utilizza per
indicare ad un client il crollo inaspettato di un server. In Linux è
Raccogliamo qui infine una serie di segnali che hanno scopi differenti non
classificabili in maniera omogenea. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\signal{SIGUSR1}] Insieme a \signal{SIGUSR2} è un segnale a disposizione
+\item[\signald{SIGUSR1}] Insieme a \signal{SIGUSR2} è un segnale a disposizione
dell'utente che lo può usare per quello che vuole. Viene generato solo
attraverso l'invocazione della funzione \func{kill}. Entrambi i segnali
possono essere utili per implementare una comunicazione elementare fra
processi diversi, o per eseguire a richiesta una operazione utilizzando un
gestore. L'azione predefinita è di terminare il processo.
-\item[\signal{SIGUSR2}] È il secondo segnale a disposizione degli utenti. Per
+\item[\signald{SIGUSR2}] È il secondo segnale a disposizione degli utenti. Per
il suo utilizzo vale esattamente quanto appena detto per \signal{SIGUSR1}.
-\item[\signal{SIGWINCH}] Il nome sta per \textit{window (size) change} e viene
+\item[\signald{SIGWINCH}] Il nome sta per \textit{window (size) change} e viene
generato in molti sistemi (GNU/Linux compreso) quando le dimensioni (in
righe e colonne) di un terminale vengono cambiate. Viene usato da alcuni
programmi testuali per riformattare l'uscita su schermo quando si cambia
dimensione a quest'ultimo. L'azione predefinita è di essere ignorato.
-\item[\signal{SIGINFO}] Il segnale indica una richiesta di informazioni. È
+\item[\signald{SIGINFO}] Il segnale indica una richiesta di informazioni. È
usato con il controllo di sessione, causa la stampa di informazioni da parte
del processo leader del gruppo associato al terminale di controllo, gli
altri processi lo ignorano. Su Linux però viene utilizzato come sinonimo di
\signal{SIGPWR} e l'azione predefinita è di terminare il processo.
-\item[\signal{SIGPWR}] Il segnale indica un cambio nello stato di
+\item[\signald{SIGPWR}] Il segnale indica un cambio nello stato di
alimentazione di un eventuale gruppo di continuità e viene usato
principalmente per segnalare l'assenza ed il ritorno della corrente. Viene
usato principalmente con \cmd{init} per attivare o fermare le procedure di
spegnimento automatico all'esaurimento delle batterie. L'azione predefinita
è di terminare il processo.
-\item[\signal{SIGSTKFLT}] Indica un errore nello stack del coprocessore
+\item[\signald{SIGSTKFLT}] Indica un errore nello stack del coprocessore
matematico, è definito solo per le architetture PC, ma è completamente
inusato. L'azione predefinita è di terminare il processo.
\end{basedescript}
ed una descrizione del segnale indicato dall'argomento \param{sig}.
Una modalità alternativa per utilizzare le descrizioni restituite da
-\func{strsignal} e \func{psignal} è quello di usare la
-\index{variabili!globali} variabile globale \var{sys\_siglist}, che è definita
-in \headfile{signal.h} e può essere acceduta con la dichiarazione:
+\func{strsignal} e \func{psignal} è quello di usare la variabile globale
+\var{sys\_siglist}, che è definita in \headfile{signal.h} e può essere
+acceduta con la dichiarazione:
\includecodesnip{listati/siglist.c}
L'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
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 \index{file!di~dispositivo} file di dispositivo, i
- socket o le pipe);
+ presenti (come per certi file di dispositivo, i socket o le \textit{pipe});
\item la scrittura sugli stessi file, nel caso in cui dati non possano essere
accettati immediatamente (di nuovo comune per i socket);
\item l'apertura di un file di dispositivo che richiede operazioni non
questa infatti, per la poca chiarezza della sintassi del C quando si vanno a
trattare puntatori a funzioni, è molto meno comprensibile. Da un confronto
con il precedente prototipo si può dedurre la definizione di
-\type{sighandler\_t} che è:
+\typed{sighandler\_t} che è:
\includecodesnip{listati/sighandler_t.c}
e cioè un puntatore ad una funzione \ctyp{void} (cioè senza valore di ritorno)
e che prende un argomento di tipo \ctyp{int}. Si noti come si devono usare le
chiamando \funcm{sysv\_signal}, una volta che si sia definita la macro
\macro{\_XOPEN\_SOURCE}. In generale, per evitare questi problemi, l'uso di
\func{signal}, che tra l'altro ha un comportamento indefinito in caso di
-processo \itindex{thread} multi-\textit{thread}, è da evitare: tutti i nuovi
-programmi devono usare \func{sigaction}.
+processo multi-\textit{thread}, è da evitare: tutti i nuovi programmi devono
+usare \func{sigaction}.
È da tenere presente che, seguendo lo standard POSIX, il comportamento di un
processo che ignora i segnali \signal{SIGFPE}, \signal{SIGILL}, o
queste funzioni era limitata dalla frequenza del timer di sistema, determinato
dal valore della costante \texttt{HZ} di cui abbiamo già parlato in
sez.~\ref{sec:proc_hierarchy}, in quanto le temporizzazioni erano calcolate in
-numero di interruzioni del timer (i cosiddetti \itindex{jiffies}
-``\textit{jiffies}''), ed era assicurato soltanto che il segnale non sarebbe
-stato mai generato prima della scadenza programmata (l'arrotondamento cioè era
-effettuato per eccesso).\footnote{questo in realtà non è del tutto vero a
- causa di un bug, presente fino al kernel 2.6.12, che in certe circostanze
- causava l'emissione del segnale con un arrotondamento per difetto.}
-
-L'uso del contatore dei \itindex{jiffies} \textit{jiffies}, un intero a 32 bit
-nella maggior parte dei casi, comportava inoltre l'impossibilità di
-specificare tempi molto lunghi. superiori al valore della costante
-\const{MAX\_SEC\_IN\_JIFFIES}, pari, nel caso di default di un valore di
-\const{HZ} di 250, a circa 99 giorni e mezzo. Con il cambiamento della
-rappresentazione effettuato nel kernel 2.6.16 questo problema è scomparso e
-con l'introduzione dei timer ad alta risoluzione (vedi
-sez.~\ref{sec:sig_timer_adv}) nel kernel 2.6.21 la precisione è diventata
-quella fornita dall'hardware disponibile.
+numero di interruzioni del timer (i cosiddetti ``\textit{jiffies}''), ed era
+assicurato soltanto che il segnale non sarebbe stato mai generato prima della
+scadenza programmata (l'arrotondamento cioè era effettuato per
+eccesso).\footnote{questo in realtà non è del tutto vero a causa di un bug,
+ presente fino al kernel 2.6.12, che in certe circostanze causava l'emissione
+ del segnale con un arrotondamento per difetto.}
+
+L'uso del contatore dei \textit{jiffies}, un intero a 32 bit nella maggior
+parte dei casi, comportava inoltre l'impossibilità di specificare tempi molto
+lunghi. superiori al valore della costante \const{MAX\_SEC\_IN\_JIFFIES},
+pari, nel caso di default di un valore di \const{HZ} di 250, a circa 99 giorni
+e mezzo. Con il cambiamento della rappresentazione effettuato nel kernel
+2.6.16 questo problema è scomparso e con l'introduzione dei timer ad alta
+risoluzione (vedi sez.~\ref{sec:sig_timer_adv}) nel kernel 2.6.21 la
+precisione è diventata quella fornita dall'hardware disponibile.
Una seconda causa di potenziali ritardi è che il segnale viene generato alla
scadenza del timer, ma poi deve essere consegnato al processo; se quest'ultimo
stato consegnato. In questo caso, per il comportamento dei segnali descritto
in sez.~\ref{sec:sig_sigchld}, un solo segnale sarà consegnato. Per questo
oggi l'uso di questa funzione è deprecato a favore degli
-\itindex{High~Resolution~Timer~(HRT)} \textit{high-resolution timer} e della
-cosiddetta \itindex{POSIX~Timer~API} \textit{POSIX Timer API}, che tratteremo
-in sez.~\ref{sec:sig_timer_adv}.
+\textit{high-resolution timer} e della cosiddetta \itindex{POSIX~Timer~API}
+\textit{POSIX Timer API}, che tratteremo in sez.~\ref{sec:sig_timer_adv}.
Dato che sia \func{alarm} che \func{setitimer} non consentono di leggere il
valore corrente di un timer senza modificarlo, è possibile usare la funzione
processo, si può completare la gestione della terminazione installando un
gestore per \signal{SIGCHLD} il cui unico compito sia quello di chiamare
\func{waitpid} per completare la procedura di terminazione in modo da evitare
-la formazione di \itindex{zombie} \textit{zombie}.\footnote{si ricordi
- comunque che dal kernel 2.6 seguendo lo standard POSIX.1-2001 per evitare di
- dover ricevere gli stati di uscita che non interessano basta impostare come
- azione predefinita quella di ignorare \signal{SIGCHLD}, nel qual caso viene
- assunta la semantica di System V, in cui il segnale non viene inviato, il
- sistema non genera \itindex{zombie} \textit{zombie} e lo stato di
- terminazione viene scartato senza dover chiamare una \func{wait}.}
+la formazione di \textit{zombie}.\footnote{si ricordi comunque che dal kernel
+ 2.6 seguendo lo standard POSIX.1-2001 per evitare di dover ricevere gli
+ stati di uscita che non interessano basta impostare come azione predefinita
+ quella di ignorare \signal{SIGCHLD}, nel qual caso viene assunta la
+ semantica di System V, in cui il segnale non viene inviato, il sistema non
+ genera \textit{zombie} e lo stato di terminazione viene scartato senza dover
+ chiamare una \func{wait}.}
In fig.~\ref{fig:sig_sigchld_handl} è mostrato il codice contenente una
implementazione generica di una funzione di gestione per \signal{SIGCHLD},
test 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 \signal{SIGCHLD}) potremo verificare che non si ha
-più la creazione di \itindex{zombie} \textit{zombie}.
+più la creazione di \textit{zombie}.
\begin{figure}[!htbp]
\footnotesize \centering
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 \itindex{zombie} \textit{zombie} per un tempo
-indefinito.
+resterebbero in stato di \textit{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
Le funzioni esaminate finora fanno riferimento alle modalità più elementari
della gestione dei segnali; non si sono pertanto ancora prese in
-considerazione le tematiche più complesse, collegate alle varie
-\itindex{race~condition} \textit{race condition} che i segnali possono
-generare e alla natura asincrona degli stessi.
+considerazione le tematiche più complesse, collegate alle varie \textit{race
+ condition} che i segnali possono generare e alla natura asincrona degli
+stessi.
Affronteremo queste problematiche in questa sezione, partendo da un esempio
che le evidenzi, per poi prendere in esame le varie funzioni che permettono di
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 \itindex{race~condition} \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 di quest'ultima, cosicché essa
-sarebbe eseguita dopo l'arrivo di \signal{SIGALRM}. In questo caso ci si
-troverebbe di fronte ad un \itindex{deadlock} deadlock, in quanto \func{pause}
-non verrebbe mai più interrotta (se non in caso di un altro segnale).
+presenta una pericolosa \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 di quest'ultima, cosicché essa sarebbe eseguita dopo l'arrivo
+di \signal{SIGALRM}. In questo caso ci si troverebbe di fronte ad un
+\textit{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 sez.~\ref{sec:proc_longjmp}) per
quello riportato in fig.~\ref{fig:sig_event_wrong}.
La logica del programma è quella di far impostare al gestore (\texttt{\small
- 14--19}) una \index{variabili!globali} variabile globale, preventivamente
-inizializzata nel programma principale, ad un diverso valore. In questo modo
-dal corpo principale del programma si potrà determinare, osservandone il
-contenuto di detta variabile, l'occorrenza o meno del segnale, ed eseguire le
-azioni conseguenti (\texttt{\small 6--11}) relative.
+ 14--19}) una variabile globale, preventivamente inizializzata nel programma
+principale, ad un diverso valore. In questo modo dal corpo principale del
+programma si potrà determinare, osservandone il contenuto di detta variabile,
+l'occorrenza o meno del segnale, ed eseguire le azioni conseguenti
+(\texttt{\small 6--11}) relative.
\begin{figure}[!htbp]
\footnotesize\centering
\end{figure}
Questo è il tipico esempio di caso, già citato in
-sez.~\ref{sec:proc_race_cond}, in cui si genera una \itindex{race~condition}
-\textit{race condition}. Infatti, in una situazione in cui un segnale è già
-arrivato (e quindi \var{flag} è già stata impostata ad 1 nel gestore) se un
-altro segnale arriva immediatamente dopo l'esecuzione del controllo
-(\texttt{\small 6}) ma prima della cancellazione di \var{flag} fatta subito
-dopo (\texttt{\small 7}), la sua occorrenza sarà perduta.
+sez.~\ref{sec:proc_race_cond}, in cui si genera una \textit{race
+ condition}. Infatti, in una situazione in cui un segnale è già arrivato (e
+quindi \var{flag} è già stata impostata ad 1 nel gestore) se un altro segnale
+arriva immediatamente dopo l'esecuzione del controllo (\texttt{\small 6}) ma
+prima della cancellazione di \var{flag} fatta subito dopo (\texttt{\small 7}),
+la sua occorrenza sarà perduta.
Questi esempi ci mostrano come per poter eseguire una gestione effettiva dei
segnali occorrono delle funzioni più sofisticate di quelle finora
quando si imposta un gestore per \signal{SIGCHLD}.\\
\const{SA\_NOCLDWAIT}& Se il segnale è \signal{SIGCHLD} e si richiede di
ignorare il segnale con \const{SIG\_IGN} allora i
- processi figli non diventano \itindex{zombie}
- \textit{zombie} quando terminano; questa
- funzionalità è stata introdotta nel kernel 2.6 e va
- a modificare il comportamento di \func{waitpid}
- come illustrato in sez.~\ref{sec:proc_wait}, se si
- installa un gestore con questo flag attivo il
- segnale \signal{SIGCHLD} viene comunque generato.\\
+ processi figli non diventano \textit{zombie} quando
+ terminano; questa funzionalità è stata introdotta
+ nel kernel 2.6 e va a modificare il comportamento
+ di \func{waitpid} come illustrato in
+ sez.~\ref{sec:proc_wait}, se si installa un gestore
+ con questo flag attivo il segnale \signal{SIGCHLD}
+ viene comunque generato.\\
\const{SA\_NODEFER} & Evita che il segnale corrente sia bloccato durante
l'esecuzione del gestore.\\
\const{SA\_NOMASK} & Nome obsoleto e sinonimo non standard di
\const{SA\_ONESHOT} & Nome obsoleto e sinonimo non standard di
\const{SA\_RESETHAND}, non deve essere più
utilizzato.\\
- \const{SA\_ONSTACK} & Stabilisce l'uso di uno \itindex{stack}
- \textit{stack} alternativo per l'esecuzione del
- gestore (vedi
+ \const{SA\_ONSTACK} & Stabilisce l'uso di uno \textit{stack} alternativo
+ per l'esecuzione del gestore (vedi
sez.~\ref{sec:sig_specific_features}).\\
\const{SA\_RESETHAND}& Ristabilisce l'azione per il segnale al valore
predefinito una volta che il gestore è stato
più dettagliate dal sistema, attraverso la struttura \struct{siginfo\_t},
riportata in fig.~\ref{fig:sig_siginfo_t}. I due campi devono essere usati in
maniera alternativa, in certe implementazioni questi campi vengono addirittura
-definiti come una \direct{union}.
+definiti come una \direct{union}.\footnote{la direttiva \direct{union} del
+ linguaggio C definisce una variabile complessa, analoga a una stuttura, i
+ cui campi indicano i diversi tipi di valori che possono essere salvati, in
+ maniera alternativa, all'interno della stessa.}
Installando un gestore di tipo \var{sa\_sigaction} diventa allora possibile
accedere alle informazioni restituite attraverso il puntatore a questa
\begin{table}[!htb]
\footnotesize
\centering
- \begin{tabular}[c]{|l|p{8cm}|}
+ \begin{tabular}[c]{|l|p{10cm}|}
\hline
\textbf{Valore} & \textbf{Significato} \\
\hline
\const{TRAP\_BRKPT} & Breakpoint sul processo.\\
\const{TRAP\_TRACE} & Trappola di tracciamento del processo.\\
\hline
- \const{CLD\_EXITED} & Il figlio è uscito.\\
- \const{CLD\_KILLED} & Il figlio è stato terminato.\\
- \const{CLD\_DUMPED} & Il figlio è terminato in modo anormale.\\
- \const{CLD\_TRAPPED} & Un figlio tracciato ha raggiunto una trappola.\\
- \const{CLD\_STOPPED} & Il figlio è stato fermato.\\
- \const{CLD\_CONTINUED}& Il figlio è ripartito.\\
+ \constd{CLD\_EXITED} & Il figlio è uscito.\\
+ \constd{CLD\_KILLED} & Il figlio è stato terminato.\\
+ \constd{CLD\_DUMPED} & Il figlio è terminato in modo anormale.\\
+ \constd{CLD\_TRAPPED} & Un figlio tracciato ha raggiunto una trappola.\\
+ \constd{CLD\_STOPPED} & Il figlio è stato fermato.\\
+ \constd{CLD\_CONTINUED}& Il figlio è ripartito.\\
\hline
\const{POLL\_IN} & Disponibili dati in ingresso.\\
\const{POLL\_OUT} & Spazio disponibile sul buffer di uscita.\\
\end{table}
Il resto della struttura \struct{siginfo\_t} è definito come una
-\direct{union} ed i valori eventualmente presenti dipendono dal segnale
+\dirct{union} ed i valori eventualmente presenti dipendono dal segnale
ricevuto, così \signal{SIGCHLD} ed i segnali \textit{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
gestore di segnale.
Si noti come, essendo la funzione estremamente semplice, essa è definita come
-\direct{inline}. Questa direttiva viene usata per dire al compilatore di
+\dirct{inline}. Questa direttiva 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
in \textit{user space}, non sono sempre adatte.
In tal caso infatti le istruzioni per creare un nuovo frame nello
-\itindex{stack} \textit{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.
+\textit{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.
\end{table}
In questo modo diventa possibile proteggere delle sezioni di codice bloccando
-l'insieme di segnali voluto per poi riabilitarli alla fine della
-\index{sezione~critica} sezione critica. La funzione permette di risolvere
-problemi come quelli mostrati in fig.~\ref{fig:sig_event_wrong}, proteggendo
-la sezione fra il controllo del flag e la sua cancellazione. La funzione può
-essere usata anche all'interno di un gestore, ad esempio per riabilitare la
-consegna del segnale che l'ha invocato, in questo caso però occorre ricordare
-che qualunque modifica alla maschera dei segnali viene perduta al ritorno
-dallo stesso.
+l'insieme di segnali voluto per poi riabilitarli alla fine della sezione
+critica. La funzione permette di risolvere problemi come quelli mostrati in
+fig.~\ref{fig:sig_event_wrong}, proteggendo la sezione fra il controllo del
+flag e la sua cancellazione. La funzione può essere usata anche all'interno
+di un gestore, ad esempio per riabilitare la consegna del segnale che l'ha
+invocato, in questo caso però occorre ricordare che qualunque modifica alla
+maschera dei segnali viene perduta al ritorno dallo stesso.
Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
-dei casi di \itindex{race~condition} \textit{race condition} restano aperte
-alcune possibilità legate all'uso di \func{pause}. Il caso è simile a quello
-del 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
-della maschera dei segnali (di solito attivandone uno specifico) insieme alla
-sospensione del processo lo standard POSIX ha previsto la funzione di sistema
+dei casi di \textit{race condition} restano aperte alcune possibilità legate
+all'uso di \func{pause}. Il caso è simile a quello del 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 della maschera dei
+segnali (di solito attivandone uno specifico) insieme alla sospensione del
+processo lo standard POSIX ha previsto la funzione di sistema
\funcd{sigsuspend}, il cui prototipo è:
\begin{funcproto}{
\var{sleep\_mask} per riattivare \signal{SIGALRM} all'esecuzione di
\func{sigsuspend}.
-In questo modo non sono più possibili \itindex{race~condition} \textit{race
- condition} dato che \signal{SIGALRM} viene disabilitato con
-\func{sigprocmask} fino alla chiamata di \func{sigsuspend}. Questo metodo è
-assolutamente generale e può essere applicato a qualunque altra situazione in
-cui si deve attendere per un segnale, i passi sono sempre i seguenti:
+In questo modo non sono più possibili \textit{race condition} dato che
+\signal{SIGALRM} viene disabilitato con \func{sigprocmask} fino alla chiamata
+di \func{sigsuspend}. Questo metodo è assolutamente generale e può essere
+applicato a qualunque 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};
\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
-\itindex{deadlock} deadlock dovuto all'arrivo del segnale prima
-dell'esecuzione di \func{sigsuspend}.
+riabilitarla immediatamente dopo, in questo modo si evita il \textit{deadlock}
+dovuto all'arrivo del segnale prima dell'esecuzione di \func{sigsuspend}.
\index{maschera dei segnali|)}
di un gestore di segnali la stessa funzione che dal segnale è stata
interrotta.
-\index{funzioni!sicure|(}
+\index{funzioni!\textit{signal safe}|(}
Il concetto è comunque più generale e porta ad una distinzione fra quelle che
POSIX chiama \textsl{funzioni insicure} (\textit{signal unsafe function}) e
\label{fig:sig_safe_functions}
\end{figure}
-\index{funzioni!sicure|)}
+\index{funzioni!\textit{signal safe}|)}
Lo standard POSIX.1-2004 modifica la lista di
fig.~\ref{fig:sig_safe_functions} aggiungendo le funzioni \func{\_Exit} e
Per questo motivo è opportuno mantenere al minimo indispensabile le operazioni
effettuate all'interno di un gestore di segnali, qualora si debbano compiere
operazioni complesse è sempre preferibile utilizzare la tecnica in cui si usa
-il gestore per impostare il valore di una qualche \index{variabili!globali}
-variabile globale, e poi si eseguono le operazioni complesse nel programma
-verificando (con tutti gli accorgimenti visti in precedenza) il valore di
-questa variabile tutte le volte che si è rilevata una interruzione dovuta ad
-un segnale.
+il gestore per impostare il valore di una qualche variabile globale, e poi si
+eseguono le operazioni complesse nel programma verificando (con tutti gli
+accorgimenti visti in precedenza) il valore di questa variabile tutte le volte
+che si è rilevata una interruzione dovuta ad un segnale.
\section{Funzionalità avanzate}
sez.~\ref{sec:sig_sigaction}, è disponibile anche con i segnali ordinari, si
applicano solo ai nuovi segnali \textit{real-time}; questi ultimi sono
accessibili in un intervallo di valori specificati dalle due costanti
-\const{SIGRTMIN} e \const{SIGRTMAX}, che specificano il numero minimo e
+\constd{SIGRTMIN} e \constd{SIGRTMAX}, che specificano il numero minimo e
massimo associato ad un segnale \textit{real-time}.
Su Linux di solito il primo valore è 33, mentre il secondo è \code{\_NSIG-1},
\end{minipage}
\normalsize
\caption{La definizione dell'unione \structd{sigval}, definita anche come
- tipo \type{sigval\_t}.}
+ tipo \typed{sigval\_t}.}
\label{fig:sig_sigval}
\end{figure}
Detto campo, identificato con il tipo di dato \type{sigval\_t}, è una
-\direct{union} di tipo \struct{sigval} (la sua definizione è in
+\dirct{union} di tipo \struct{sigval} (la sua definizione è in
fig.~\ref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico,
se usata nella forma \var{sival\_int}, o un puntatore, se usata nella forma
\var{sival\_ptr}. L'unione viene usata dai segnali \textit{real-time} e da
Lo standard POSIX.1b definisce inoltre delle nuove funzioni di sistema che
permettono di gestire l'attesa di segnali specifici su una coda, esse servono
-in particolar modo nel caso dei \itindex{thread} \textit{thread}, in cui si
-possono usare i segnali \textit{real-time} come meccanismi di comunicazione
-elementare; la prima di queste è \funcd{sigwait}, il cui prototipo è:
+in particolar modo nel caso dei \textit{thread}, in cui si possono usare i
+segnali \textit{real-time} come meccanismi di comunicazione elementare; la
+prima di queste è \funcd{sigwait}, il cui prototipo è:
\begin{funcproto}{
\fhead{signal.h}
prevedibile.
Lo standard POSIX.1b definisce altre due funzioni di sistema, anch'esse usate
-prevalentemente con i \itindex{thread} \textit{thread}; \funcd{sigwaitinfo} e
+prevalentemente con i \textit{thread}; \funcd{sigwaitinfo} e
\funcd{sigtimedwait}, i relativi prototipi sono:
\begin{funcproto}{
sez.~\ref{sec:proc_hierarchy}, è data dal valore della costante \texttt{HZ}.
I contatori usati per il calcolo dei tempi infatti erano basati sul numero di
-\itindex{jiffies} \textit{jiffies} che vengono incrementati ad ogni
-\textit{clock tick} del timer di sistema, il che comportava anche, come
-accennato in sez.~\ref{sec:sig_alarm_abort} per \func{setitimer}, problemi per
-il massimo periodo di tempo copribile da alcuni di questi orologi, come quelli
-associati al \textit{process time} almeno fino a quando, con il kernel 2.6.16,
-non è stato rimosso il limite di un valore a 32 bit per i \textit{jiffies}.
+\textit{jiffies} che vengono incrementati ad ogni \textit{clock tick} del
+timer di sistema, il che comportava anche, come accennato in
+sez.~\ref{sec:sig_alarm_abort} per \func{setitimer}, problemi per il massimo
+periodo di tempo copribile da alcuni di questi orologi, come quelli associati
+al \textit{process time} almeno fino a quando, con il kernel 2.6.16, non è
+stato rimosso il limite di un valore a 32 bit per i \textit{jiffies}.
\itindbeg{POSIX~Timer~API}
sez.~\ref{sec:sys_cpu_times}, nel totale di
\textit{system time} e \textit{user time})
comprensivo di tutto il tempo di CPU usato
- da eventuali \itindex{thread}
- \textit{thread}.\\
+ da eventuali \textit{thread}.\\
\const{CLOCK\_THREAD\_CPUTIME\_ID}& Contatore del tempo di CPU
(\textit{user time} e \textit{system time})
- usato da un singolo \itindex{thread}
- \textit{thread}.\\
+ usato da un singolo \textit{thread}.\\
\hline
\const{CLOCK\_MONOTONIC\_RAW}&Simile al precedente, ma non subisce gli
aggiustamenti dovuti all'uso di NTP (viene
% \const{} & .\\
\hline
\end{tabular}
- \caption{Valori possibili per una variabile di tipo \type{clockid\_t}
+ \caption{Valori possibili per una variabile di tipo \typed{clockid\_t}
usata per indicare a quale tipo di orologio si vuole fare riferimento.}
\label{tab:sig_timer_clockid_types}
\end{table}
segnale è stato installato con
\const{SA\_SIGINFO} gli verrà restituito il
valore specificato con \var{sigev\_value} (una
- \direct{union} \texttt{sigval}, la cui definizione
+ \dirct{union} \texttt{sigval}, la cui definizione
è in fig.~\ref{fig:sig_sigval}) come valore del
campo \var{si\_value} di \struct{siginfo\_t}.\\
\const{SIGEV\_THREAD} & La notifica viene effettuata creando un nuovo
- \itindex{thread} \textit{thread} che esegue la
- funzione di notifica specificata da
+ \textit{thread} che esegue la funzione di
+ notifica specificata da
\var{sigev\_notify\_function} con argomento
\var{sigev\_value}. Se questo è diverso da
\val{NULL}, il \textit{thread} viene creato con
l'identificatore del timer come valore per \var{sigev\_value.sival\_int}.
Il terzo argomento deve essere l'indirizzo di una variabile di tipo
-\type{timer\_t} dove sarà scritto l'identificativo associato al timer appena
+\typed{timer\_t} dove sarà scritto l'identificativo associato al timer appena
creato, da usare in tutte le successive funzioni di gestione. Una volta creato
questo identificativo resterà univoco all'interno del processo stesso fintanto
che il timer non viene cancellato.
escluderne l'avvenuto invio al momento della chiamata non significa nulla
rispetto a quanto potrebbe essere in un qualunque momento successivo.
+\itindbeg{stack}
+
Una delle caratteristiche di BSD, disponibile anche in Linux, è la possibilità
-di usare uno \itindex{stack} \textit{stack} alternativo per i segnali; è cioè
-possibile fare usare al sistema un altro \itindex{stack} \textit{stack}
-(invece di quello relativo al processo, vedi sez.~\ref{sec:proc_mem_layout})
-solo durante l'esecuzione di un gestore. L'uso di uno \textit{stack}
-alternativo è del tutto trasparente ai gestori, occorre però seguire una certa
-procedura:
+di usare uno \textit{stack} alternativo per i segnali; è cioè possibile fare
+usare al sistema un altro \textit{stack} (invece di quello relativo al
+processo, vedi sez.~\ref{sec:proc_mem_layout}) solo durante l'esecuzione di un
+gestore. L'uso di uno \textit{stack} alternativo è del tutto trasparente ai
+gestori, occorre però seguire una certa procedura:
\begin{enumerate*}
\item allocare un'area di memoria di dimensione sufficiente da usare come
\textit{stack} alternativo;
memoria con \code{malloc}; in \headfile{signal.h} sono definite due costanti,
\const{SIGSTKSZ} e \const{MINSIGSTKSZ}, che possono essere utilizzate per
allocare una quantità di spazio opportuna, in modo da evitare overflow. La
-prima delle due è la dimensione canonica per uno \itindex{stack}
-\textit{stack} di segnali e di norma è sufficiente per tutti gli usi normali.
+prima delle due è la dimensione canonica per uno \textit{stack} di segnali e
+di norma è sufficiente per tutti gli usi normali.
La seconda è lo spazio che occorre al sistema per essere in grado di lanciare
il gestore e la dimensione di uno \textit{stack} alternativo deve essere
sempre maggiore di questo valore. Quando si conosce esattamente quanto è lo
spazio necessario al gestore gli si può aggiungere questo valore per allocare
-uno \itindex{stack} \textit{stack} di dimensione sufficiente.
+uno \textit{stack} di dimensione sufficiente.
-Come accennato, per poter essere usato, lo \itindex{stack} \textit{stack} per
-i segnali deve essere indicato al sistema attraverso la funzione
-\funcd{sigaltstack}; il suo prototipo è:
+Come accennato, per poter essere usato, lo \textit{stack} per i segnali deve
+essere indicato al sistema attraverso la funzione \funcd{sigaltstack}; il suo
+prototipo è:
\begin{funcproto}{
\fhead{signal.h}
La funzione prende come argomenti puntatori ad una struttura di tipo
\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
-\itindex{stack} \textit{stack} da installare e quello corrente (che viene
-restituito dalla funzione per un successivo ripristino).
+\textit{stack} da installare e quello corrente (che viene restituito dalla
+funzione per un successivo ripristino).
\begin{figure}[!htb]
\footnotesize \centering
\end{figure}
Il campo \var{ss\_sp} di \struct{stack\_t} indica l'indirizzo base dello
-\itindex{stack} \textit{stack}, mentre \var{ss\_size} ne indica la dimensione;
-il campo \var{ss\_flags} invece indica lo stato dello \textit{stack}.
-Nell'indicare un nuovo \textit{stack} occorre inizializzare \var{ss\_sp} e
-\var{ss\_size} rispettivamente al puntatore e alla dimensione della memoria
-allocata, mentre \var{ss\_flags} deve essere nullo. Se invece si vuole
-disabilitare uno \textit{stack} occorre indicare \const{SS\_DISABLE} come
-valore di \var{ss\_flags} e gli altri valori saranno ignorati.
+\textit{stack}, mentre \var{ss\_size} ne indica la dimensione; il campo
+\var{ss\_flags} invece indica lo stato dello \textit{stack}. Nell'indicare un
+nuovo \textit{stack} occorre inizializzare \var{ss\_sp} e \var{ss\_size}
+rispettivamente al puntatore e alla dimensione della memoria allocata, mentre
+\var{ss\_flags} deve essere nullo. Se invece si vuole disabilitare uno
+\textit{stack} occorre indicare \const{SS\_DISABLE} come valore di
+\var{ss\_flags} e gli altri valori saranno ignorati.
Se \param{oss} non è nullo verrà restituito dalla funzione indirizzo e
-dimensione dello \itindex{stack} \textit{stack} corrente nei relativi campi,
-mentre \var{ss\_flags} potrà assumere il valore \const{SS\_ONSTACK} se il
-processo è in esecuzione sullo \textit{stack} alternativo (nel qual caso non è
-possibile cambiarlo) e \const{SS\_DISABLE} se questo non è abilitato.
-
-In genere si installa uno \itindex{stack} \textit{stack} alternativo per i
-segnali quando si teme di avere problemi di esaurimento dello \textit{stack}
-standard o di superamento di un limite (vedi
-sez.~\ref{sec:sys_resource_limit}) imposto con chiamate del tipo
-\code{setrlimit(RLIMIT\_STACK, \&rlim)}. In tal caso infatti si avrebbe un
-segnale di \signal{SIGSEGV}, che potrebbe essere gestito soltanto avendo
-abilitato uno \itindex{stack} \textit{stack} alternativo.
+dimensione dello \textit{stack} corrente nei relativi campi, mentre
+\var{ss\_flags} potrà assumere il valore \const{SS\_ONSTACK} se il processo è
+in esecuzione sullo \textit{stack} alternativo (nel qual caso non è possibile
+cambiarlo) e \const{SS\_DISABLE} se questo non è abilitato.
+
+In genere si installa uno \textit{stack} alternativo per i segnali quando si
+teme di avere problemi di esaurimento dello \textit{stack} standard o di
+superamento di un limite (vedi sez.~\ref{sec:sys_resource_limit}) imposto con
+chiamate del tipo \code{setrlimit(RLIMIT\_STACK, \&rlim)}. In tal caso
+infatti si avrebbe un segnale di \signal{SIGSEGV}, che potrebbe essere gestito
+soltanto avendo abilitato uno \textit{stack} alternativo.
Si tenga presente che le funzioni chiamate durante l'esecuzione sullo
\textit{stack} alternativo continueranno ad usare quest'ultimo, che, al
-contrario di quanto avviene per lo \itindex{stack} \textit{stack} ordinario
-dei processi, non si accresce automaticamente (ed infatti eccederne le
-dimensioni può portare a conseguenze imprevedibili). Si ricordi infine che
-una chiamata ad una funzione della famiglia \func{exec} cancella ogni
-\textit{stack} alternativo.
+contrario di quanto avviene per lo \textit{stack} ordinario dei processi, non
+si accresce automaticamente (ed infatti eccederne le dimensioni può portare a
+conseguenze imprevedibili). Si ricordi infine che una chiamata ad una
+funzione della famiglia \func{exec} cancella ogni \textit{stack} alternativo.
+
+\itindend{stack}
Abbiamo visto in fig.~\ref{fig:sig_sleep_incomplete} come si possa usare
\func{longjmp} per uscire da un gestore rientrando direttamente nel corpo
\end{funcproto}
Le due funzioni prendono come primo argomento la variabile su cui viene
-salvato il contesto dello \itindex{stack} \textit{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.
+salvato il contesto dello \textit{stack} per permettere il salto non-locale;
+nel caso specifico essa è di tipo \typed{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}
diverso da zero la maschera dei valori verrà salvata in \param{env} insieme al
-contesto dello \itindex{stack} \textit{stack} usato per il salto non
-locale. Se così si è fatto la maschera dei segnali verrà ripristinata in una
-successiva chiamata a \func{siglongjmp}. Quest'ultima, a parte l'uso di un
-valore di \param{env} di tipo \type{sigjmp\_buf}, è assolutamente identica a
-\func{longjmp}.
+contesto dello \textit{stack} usato per il salto non locale. Se così si è
+fatto la maschera dei segnali verrà ripristinata in una successiva chiamata a
+\func{siglongjmp}. Quest'ultima, a parte l'uso di un valore di \param{env} di
+tipo \type{sigjmp\_buf}, è assolutamente identica a \func{longjmp}.
% TODO: se e quando si troverà un argomento adeguato inserire altre funzioni
projects / gapil.git / blobdiff