Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Passer des parametres aux handler de signaux
Hello,
J'aimerai utiliser des variables (exemple, fclose sur un FILE*, incrémentation, affichage) dans une fonction handler levée par signal. Mais comment acceder aux variables du programme ? j ne vais quand même pas tout déclarer en global comme je le vois dans les tutos ?!
all your base are belong to us.
fclose n'est pas garantie réentrante, tu n'as donc pas le droit de l'utiliser dans ton handler.
"The quieter you become, the more you are able to hear"
"Plus vous êtes silencieux, plus vous êtes capable d'entendre"
tu ne demandes pas pourquoi les tutos font ça ??Envoyé par TheDrev
C'était un manque à la conception de la fonction, de ne pas avoir de paramètre void* comme paramètre de passage.
Le seul autre moyen est d'utiliser sigaction, qui a une structure.
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
ou une structure static
Bonjour,
Un handler de signal doit en faire le moins possible. C'est à dire que, AU PLUS, il doit changer l'état d'une varaible de type "raisonnablement simple" (short, int long, bool, ..., mais certainement pas une chaine de caractères).
Donc la solution est que ton handler change une variable, et qu'ensuite, selon la valeur de ladite variable, tu appelles ou non la fonction qui fera le traitement que tu souhaites.
et c'est déjà trop :
If the signal occurs other than as the result of calling the abort or raise function, the
behavior is undefined if the signal handler refers to any object with static storage duration
other than by assigning a value to an object declared as volatile sig_atomic_t, or
the signal handler calls any function in the standard library other than the abort
function, the _Exit function, or the signal function with the first argument equal to
the signal number corresponding to the signal that caused the invocation of the handler.
Furthermore, if such a call to the signal function results in a SIG_ERR return, the
value of errno is indeterminate.
"The quieter you become, the more you are able to hear"
"Plus vous êtes silencieux, plus vous êtes capable d'entendre"
oui, faut pas charrier quand même
Une utilisation intensive des signaux et signaux handlers prouvent (encore une fois) qu'entre la théorie et la pratique il y a un monde....
Si ce que tu cites était le cas, les signaux n'auraient aucun intérêt...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Je ne suis pas d'accord avec toi, tout ce que cela prouve c'est que peu de gens savent se servir des signaux, pire encore, peu de gens ont compris l'utilité des signaux.oui, faut pas charrier quand même
Une utilisation intensive des signaux et signaux handlers prouvent (encore une fois
Si ce que tu cites était le cas, les signaux n'auraient aucun intérêt...
Autrement,il y a des solutions pour ceux qui voudrait pouvoir utiliser n'importe quelle fonction suite à la réception d'un signal : libevent, mais c'est POSIX only (ça ne peut pas être fais en C standard).
"The quieter you become, the more you are able to hear"
"Plus vous êtes silencieux, plus vous êtes capable d'entendre"
je te signale que, dans ce que tu cites, la partie importante est :
Donc, lorsqu'on utilise les signaux via quelque chose de "normal" (du style définir une fonction signal-handler pour tel ou tel type de signal via par exemple signal, qui fait un raise), ça ne pose aucun problèmeIf the signal occurs other than as the result of calling the abort or raise function, the behavior is undefined if the signal handler refers to any object with static storage duration
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
relis la citation ,tu ne l'a manifestement pas comprise.je te signale que, dans ce que tu cites, la partie importante est :
Donc, lorsqu'on utilise les signaux via quelque chose de "normal" (du style définir une fonction signal-handler pour tel ou tel type de signal via par exemple signal, qui fait un raise), ça ne pose aucun problème
"The quieter you become, the more you are able to hear"
"Plus vous êtes silencieux, plus vous êtes capable d'entendre"
re-lis toi-même
If the signal occurs other than as the result of calling the abort or raise function, the behavior is undefined if the signal handler refers to any object with static storage duration other than by assigning a value to an object declared as volatile sig_atomic_t, or the signal handler calls any function in the standard library other than the abort function, the _Exit function, or the signal function with the first argument equal to the signal number corresponding to the signal that caused the invocation of the handler.
Furthermore, if such a call to the signal function results in a SIG_ERR return, the value of errno is indeterminate.Si le signal n'est ni le résultat d'un appel à abort ni d'un appel à raise, alors le comportement est indéfini si le signal handler se réfère à n'importe quel objet de classe static autrement que par l'assignation d'une valeur d'un objet déclaré comme volatile sig_atomic_t, ou si le signal handler appelle n'importe quelle fonction de la biblothèque standard autre que la fonction abort, la fonction _Exit, ou la fonction signal où le premier argument est égal au numéro du signal qui a provoqué l'invocation du handler.
De plus, si un tel appel à la fonction de signal provoque un retour de type
SIG_ERR, la valeur de errno est indéterménée
Ce qui, en clair, veut dire que ce comportement n'est valable que dans la fonction de la bibliothèque standard qui appelle ton signal handler (signal).
Quand tu fais appel à la fonction signal, c'est elle qui va avoir cette limitation : regarde la dernière partie de la phrase avant le dernier paragraphe....
Lorsque toi tu fabriques un signal-handler, tu ne te préocuppes pas de faire un raise ou un abort, si ??
La manière dont cela se passe est :
- une fonction de la bibliothèque rencontre une condition de signal.
- Elle fait un raise ou un abort
- qui provoque l'appel de la fonction signal de la bibliothèque. (signal handler général de la bibliothèque)
- Qui, limitée par les contraintes décrites ci-dessus, appelle le signal-handler enregistré ..
- qui, lui, n'est plus limité par la contrainte
PS: ce que tu décris ne serait valable que si tu voulais refaire toi-même ton propre signal-handler bas niveau..
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Le seul type autorisé est sig_atomic_t qui, à ma connaissance est un entier...
Pas de Wi-Fi à la maison : CPL
re-lis toi-même
Ce qui, en clair, veut dire que ce comportement n'est valable que dans la fonction de la bibliothèque standard qui appelle ton signal handler (signal).
Quand tu fais appel à la fonction signal, c'est elle qui va avoir cette limitation : regarde la dernière partie de la phrase avant le dernier paragraphe....
Lorsque toi tu fabriques un signal-handler, tu ne te préocuppes pas de faire un raise ou un abort, si ??
La manière dont cela se passe est :
- une fonction de la bibliothèque rencontre une condition de signal.
- Elle fait un raise ou un abort
- qui provoque l'appel de la fonction signal de la bibliothèque. (signal handler général de la bibliothèque)
- Qui, limitée par les contraintes décrites ci-dessus, appelle le signal-handler enregistré ..
- qui, lui, n'est plus limité par la contrainte
PS: ce que tu décris ne serait valable que si tu voulais refaire toi-même ton propre signal-handler bas niveau..
Alors tu as mal compris :
Le comportement est indéterminé dans les cas cités si le signal n'a pas été "lancé" par un appel dans ton code à abort() ou à raise(). Un exemple simple est la fonction alarm(). Dans le gestionnaire du signal SIGALRM, tu dois t'en tenir au contrainte décrite par la norme. En revanche, je suis dans mon code, j'appelle explicitement raise() ou abort(), alors dans ce cas je peux faire tout ce que je veux de le gestionnaire, c'est assez logique quand on y pense puisque ça n'est plus asynchrone.
C'est comme ça que je l'ai compris, c'est comme ça que Stevens la compris ainsi que le CERT : http://https://www.securecoding.cert...+Signals+(SIG).
"The quieter you become, the more you are able to hear"
"Plus vous êtes silencieux, plus vous êtes capable d'entendre"
c'est exactement ce que je dis...
Pas dans ton signal-handler ....
Je n'ai jamais appelé directement raise ou abort .. Toi si ??????????
Quand tu fais appel à SIGALRM, c'est toi qui appelles raise ???
Quand tu écoutes un socket, c'est toi qui appelles raise pour un SIGIO ???
Réponses : non et non...
a) Tu fais appel par exemple à setitimer, qui, en interne, fait le raise du SIGALRM.
b) Tu fais appel à recv , ou à read, ou listen, ou select, et c'est ces fonctions là qui font le raise...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Eh bien pour moi, ça veut dire justement que ton handler pour SIGALRM ou SIGIO est sujet à toutes ces restrictions...
Enfin si ça se trouve, ces restrictions s'appliquent au C standard et sont relaxées sous POSIX... (d'ailleurs, il me semble que SIGALRM n'existe pas en standard)
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Rien n'indique que l'implémentation doit utiliser raise() pour envoyer un signal (dailleurs sous linux elle utilise sigaction()), tu te trompes, raise() est bien une fonction utilisateur. Je n'utilise pas personnellement raise() ou abort() mais je n'interdis en rien leur usage.c'est exactement ce que je dis...
Pas dans ton signal-handler ....
Je n'ai jamais appelé directement raise ou abort .. Toi si ??????????
Quand tu fais appel à SIGALRM, c'est toi qui appelles raise ???
Quand tu écoutes un socket, c'est toi qui appelles raise pour un SIGIO ???
Réponses : non et non...
a) Tu fais appel par exemple à setitimer, qui, en interne, fait le raise du SIGALRM.
b) Tu fais appel à recv , ou à read, ou rien (asynchrone), et c'est ces fonctions là qui font le raise...
"The quieter you become, the more you are able to hear"
"Plus vous êtes silencieux, plus vous êtes capable d'entendre"
sauf que toute ton argumentation tient là-dessus...
Encore une fois, la contrainte est pour quelqu'un qui appelerais directement raise ou abort....
Ce qui n'est pas le cas général, ni le cas du PO...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Exact, on peut utiliser plus de fonctions, mais la restriction reste la même pour les variables statiques.
"The quieter you become, the more you are able to hear"
"Plus vous êtes silencieux, plus vous êtes capable d'entendre"
If the signal occurs other than as the result of calling the abort or raise function
"The quieter you become, the more you are able to hear"
"Plus vous êtes silencieux, plus vous êtes capable d'entendre"
ou si le signal handler appelle n'importe quelle fonction de la biblothèque standard autre que la fonction abort, la fonction _Exit, ou la fonction signal où le premier argument est égal au numéro du signal qui a provoqué l'invocation du handler.
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager