Gestion de signaux ("signal handling")

Le
Lucas Levrel
Bonjour,

Je m'instruis sur ce sujet en lisant le manuel de la bibliothèque C GNU. À
la section 24.4.2 je lis ceci :
(http://www.gnu.org/software/libc/manual/html_node/Termination-in-Handler.html#Termination-in-Handler)
Handler functions that terminate the program are typically used to cause
orderly cleanup or recovery from program error signals and interactive
interrupts.

The cleanest way for a handler to terminate the process is to raise the
same signal that ran the handler in the first place. Here is how to do
this:
volatile sig_atomic_t fatal_error_in_progress = 0;

void
fatal_error_signal (int sig)
{
/* Since this handler is established for more than one kind of signal,
it might still get invoked recursively by delivery of some other kind
of signal. Use a static variable to keep track of that. */
if (fatal_error_in_progress)
raise (sig);
fatal_error_in_progress = 1;

/* Now do the clean up actions:
- reset terminal modes
- kill child processes
- remove lock files */


/* Now reraise the signal. We reactivate the signal's
default handling, which is to terminate the process.
We could just call exit or abort,
but reraising the signal sets the return status
from the process correctly. */
signal (sig, SIG_DFL);
raise (sig);
}

Je ne comprends pas le test. Supposons qu'un premier signal A provoque
l'exécution de fatal_error_signal ; le test est faux, donc pas d'action,
puis fatal_error_in_progress est mis à 1. Si un autre signal B interrompt
alors l'exécution, cela appelle fatal_error_signal(B) ; comme
fatal_error_in_progress est à 1, le test est vrai, et on fait raise(B) !
On tourne en boucle là, non ?

Pouvez-vous m'aider à comprendre ? Merci.

--
LL
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Antoine Leca
Le #19320221
Le 12/05/2009 14:28Z, Lucas Levrel écrivit :
Je m'instruis sur ce sujet en lisant le manuel de la bibliothèque C GNU. À
la section 24.4.2 je lis ceci :


<couic>
Je ne comprends pas le test. Supposons


<couic>
Pouvez-vous m'aider à comprendre ? Merci.



Je pense que tu auras de bien meilleurs commentaires sur le forum dédié
au systèmes d'exploitation Unix et dérivés, vers lequel je redirige ce fil.


Antoine
--
Message original :
Newsgroups: fr.comp.lang.c
Subject: Gestion de signaux ("signal handling")
Date: Tue, 12 May 2009 16:28:31 +0200
Organization: Service de news de lacave.net
Lines: 50
Message-ID: NNTP-Posting-Host: exafs.univ-paris12.fr
NNTP-Posting-Date: Tue, 12 May 2009 14:28:32 +0000 (UTC)
Bonjour,

Je m'instruis sur ce sujet en lisant le manuel de la bibliothèque C GNU. À
la section 24.4.2 je lis ceci :
(http://www.gnu.org/software/libc/manual/html_node/Termination-in-Handler.html#Termination-in-Handler)
Handler functions that terminate the program are typically used to cause
orderly cleanup or recovery from program error signals and interactive
interrupts.

The cleanest way for a handler to terminate the process is to raise the
same signal that ran the handler in the first place. Here is how to do
this:
volatile sig_atomic_t fatal_error_in_progress = 0;

void
fatal_error_signal (int sig)
{
/* Since this handler is established for more than one kind of
signal,
it might still get invoked recursively by delivery of some
other kind
of signal. Use a static variable to keep track of that. */
if (fatal_error_in_progress)
raise (sig);
fatal_error_in_progress = 1;

/* Now do the clean up actions:
- reset terminal modes
- kill child processes
- remove lock files */
...

/* Now reraise the signal. We reactivate the signal's
default handling, which is to terminate the process.
We could just call exit or abort,
but reraising the signal sets the return status
from the process correctly. */
signal (sig, SIG_DFL);
raise (sig);
}

Je ne comprends pas le test. Supposons qu'un premier signal A provoque
l'exécution de fatal_error_signal ; le test est faux, donc pas d'action,
puis fatal_error_in_progress est mis à 1. Si un autre signal B interrompt
alors l'exécution, cela appelle fatal_error_signal(B) ; comme
fatal_error_in_progress est à 1, le test est vrai, et on fait raise(B) !
On tourne en boucle là, non ?

Pouvez-vous m'aider à comprendre ? Merci.

--
LL
Cyrille Lefevre
Le #19322131
Antoine Leca a écrit :
Le 12/05/2009 14:28Z, Lucas Levrel écrivit :
Je m'instruis sur ce sujet en lisant le manuel de la bibliothèque C GNU. À
la section 24.4.2 je lis ceci :


<couic>
Je ne comprends pas le test. Supposons


<couic>
Pouvez-vous m'aider à comprendre ? Merci.



Je pense que tu auras de bien meilleurs commentaires sur le forum déd ié
au systèmes d'exploitation Unix et dérivés, vers lequel je rediri ge ce fil.





Bonjour,

si ma mémoire est bonne, lors d'un traitement d'un signal donnée, ce
même signal est bloqué jusqu'à la fin du handler, tu ne peux donc
recevoir de nouveau ce même signal.
pour autant, tu sembles avoir raison dans le cas ou le même handler est
utilisé pour des signaux différents...
conclusion : mauvais manuel, changer manuel :-)

Cordialement,

Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%
supprimer "%nospam% et ".invalid" pour me repondre.
totof2000
Le #19324001
>
si ma mémoire est bonne, lors d'un traitement d'un signal donnée, ce
même signal est bloqué jusqu'à la fin du handler, tu ne peux donc
recevoir de nouveau ce même signal.
pour autant, tu sembles avoir raison dans le cas ou le même handler est
utilisé pour des signaux différents...
conclusion : mauvais manuel, changer manuel :-)



Mauvaise bibliothèque, changer bibliothèque .... Je pense que c'est
mieux :)

Cordialement.
Lucas Levrel
Le #19341931
Le 13 mai 2009, totof2000 a écrit :
Mauvaise bibliothèque, changer bibliothèque .... Je pense que c'est
mieux :)



Mais encore ?

--
LL
Publicité
Poster une réponse
Anonyme