IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

POSIX C Discussion :

Passer des parametres aux handler de signaux


Sujet :

POSIX C

  1. #1
    Membre actif
    Avatar de TheDrev
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    310
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Novembre 2006
    Messages : 310
    Points : 263
    Points
    263
    Par défaut 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 ?!

  2. #2
    Membre émérite Avatar de nicolas.sitbon
    Profil pro
    Inscrit en
    Août 2007
    Messages
    2 015
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations forums :
    Inscription : Août 2007
    Messages : 2 015
    Points : 2 280
    Points
    2 280
    Par défaut
    fclose n'est pas garantie réentrante, tu n'as donc pas le droit de l'utiliser dans ton handler.

  3. #3
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Points : 17 923
    Points
    17 923
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par TheDrev Voir le message
    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 ?!
    tu ne demandes pas pourquoi les tutos font ça ??

    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.

  4. #4
    Membre actif
    Profil pro
    Étudiant
    Inscrit en
    Juillet 2004
    Messages
    230
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Juillet 2004
    Messages : 230
    Points : 250
    Points
    250
    Par défaut
    ou une structure static

  5. #5
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 150
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 150
    Points : 28 129
    Points
    28 129
    Par défaut
    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.

  6. #6
    Membre émérite Avatar de nicolas.sitbon
    Profil pro
    Inscrit en
    Août 2007
    Messages
    2 015
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations forums :
    Inscription : Août 2007
    Messages : 2 015
    Points : 2 280
    Points
    2 280
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    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).
    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.

  7. #7
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Points : 17 923
    Points
    17 923
    Billets dans le blog
    2
    Par défaut
    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...

  8. #8
    Membre émérite Avatar de nicolas.sitbon
    Profil pro
    Inscrit en
    Août 2007
    Messages
    2 015
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations forums :
    Inscription : Août 2007
    Messages : 2 015
    Points : 2 280
    Points
    2 280
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    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...
    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.
    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).

  9. #9
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Points : 17 923
    Points
    17 923
    Billets dans le blog
    2
    Par défaut
    je te signale que, dans ce que tu cites, la partie importante est :

    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
    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

  10. #10
    Membre émérite Avatar de nicolas.sitbon
    Profil pro
    Inscrit en
    Août 2007
    Messages
    2 015
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations forums :
    Inscription : Août 2007
    Messages : 2 015
    Points : 2 280
    Points
    2 280
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    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
    relis la citation ,tu ne l'a manifestement pas comprise.

  11. #11
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Points : 17 923
    Points
    17 923
    Billets dans le blog
    2
    Par défaut
    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..

  12. #12
    Expert éminent sénior
    Avatar de Emmanuel Delahaye
    Profil pro
    Retraité
    Inscrit en
    Décembre 2003
    Messages
    14 512
    Détails du profil
    Informations personnelles :
    Âge : 68
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2003
    Messages : 14 512
    Points : 20 985
    Points
    20 985
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    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).
    Le seul type autorisé est sig_atomic_t qui, à ma connaissance est un entier...

  13. #13
    Membre émérite Avatar de nicolas.sitbon
    Profil pro
    Inscrit en
    Août 2007
    Messages
    2 015
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations forums :
    Inscription : Août 2007
    Messages : 2 015
    Points : 2 280
    Points
    2 280
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    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).

  14. #14
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Points : 17 923
    Points
    17 923
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par nicolas.sitbon Voir le message
    Dans le gestionnaire du signal SIGALRM, tu dois t'en tenir au contrainte décrite par la norme.
    c'est exactement ce que je dis...

    Pas dans ton signal-handler ....


    Citation Envoyé par nicolas.sitbon Voir le message
    En revanche, je suis dans mon code, j'appelle explicitement raise() ou abort(),


    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...

  15. #15
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 382
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 382
    Points : 41 589
    Points
    41 589
    Par défaut
    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)

  16. #16
    Membre émérite Avatar de nicolas.sitbon
    Profil pro
    Inscrit en
    Août 2007
    Messages
    2 015
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations forums :
    Inscription : Août 2007
    Messages : 2 015
    Points : 2 280
    Points
    2 280
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    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...
    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.

  17. #17
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Points : 17 923
    Points
    17 923
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par nicolas.sitbon Voir le message
    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.
    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...

  18. #18
    Membre émérite Avatar de nicolas.sitbon
    Profil pro
    Inscrit en
    Août 2007
    Messages
    2 015
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations forums :
    Inscription : Août 2007
    Messages : 2 015
    Points : 2 280
    Points
    2 280
    Par défaut
    Citation Envoyé par Médinoc Voir le message
    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)
    Exact, on peut utiliser plus de fonctions, mais la restriction reste la même pour les variables statiques.

  19. #19
    Membre émérite Avatar de nicolas.sitbon
    Profil pro
    Inscrit en
    Août 2007
    Messages
    2 015
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations forums :
    Inscription : Août 2007
    Messages : 2 015
    Points : 2 280
    Points
    2 280
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    Encore une fois, la contrainte est pour quelqu'un qui appelerais directement raise ou abort....
    If the signal occurs other than as the result of calling the abort or raise function

  20. #20
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Points : 17 923
    Points
    17 923
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Médinoc Voir le message
    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)
    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.

Discussions similaires

  1. Réponses: 2
    Dernier message: 21/05/2006, 10h30
  2. passer des parametres à l'application
    Par wickramben dans le forum JWS
    Réponses: 2
    Dernier message: 12/04/2006, 20h07
  3. [String] passer des minuscules aux majuscules
    Par Lady_jade dans le forum Langage
    Réponses: 5
    Dernier message: 19/10/2005, 11h03
  4. Réponses: 2
    Dernier message: 04/10/2005, 21h54
  5. [script SQL]comment passer des parametres a un scrip sql?
    Par la7su dans le forum Langage SQL
    Réponses: 5
    Dernier message: 23/03/2005, 11h55

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo