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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Antoine Leca
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
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: <Pine.LNX.4.64.0905121611410.22222@coulomb.univ-paris12.fr>
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 ?
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
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.
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%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
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
> 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.
>
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 :)
> 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 13 mai 2009, totof2000 a écrit :
Mauvaise bibliothèque, changer bibliothèque .... Je pense que c'est mieux :)
Mais encore ?
-- LL
Le 13 mai 2009, totof2000 a écrit :
Mauvaise bibliothèque, changer bibliothèque .... Je pense que c'est
mieux :)
