Version imprimable
Bonjour,
Voilà, j'aurais besoin à l'intérieur d'une classe de faire un traitant de signaux car celui-ci doit avoir accès aux attributs. Seulement, si je déclare le traitant comme une méthode de la classe, le typage n'est pas respecté (pour la structure sigaction).
Je voudrais savoir comment je peux m'arranger ... est-ce que passer par une fonction static prenant en paramètre un pointeur sur this et renvoie la méthode de traitant semble judicieux (ça fait un peu "cuisine" quand même) ?
Salut,
Ca fait un peu cuisine mais il faut mettre la main dans la tambouille à partir du moment où ton interface est en C et demande explicitement un pointeur de fonction. F.A.Q : Pourquoi ne peut-on pas passer une fonction membre là où on attend un pointeur de fonction ?
Oui je l'avais lu ce paragraphe dans la F.A.Q, c'est pour ça que je voulais partir sur cette solution ...Citation:
Envoyé par 3DArchi
Seulement, un traitant de signal renvoie void et prend un int. Or cette solution me propose de passer par une fonction renvoyant void * et prend void *. Je ne peux donc pas, à l'intérieur de mon traitant, réinterpréter un pointeur car je ne peux pas lui donner en paramètre ...
Les signaux posix ne permettent pas de passer un contexte. Mais d'un autre côté, ils sont destinés (au mieux) à un thread (souvent plutôt un processus), pas à un objet en particulier.
Si c'est pour de la communication inter-thread, je te suggèrerai bien de revoir le mécanisme si tu peux pour utiliser autre chose (file d'attente, par exemple). Si c'est pour de l'inter-process, pas d'autre choix que de gérer toi-même un contexte (variable statique ?)
Salut,
Comme le dit white_tentacle, pas d'autres choix que de passer par une variable statique à un moment donnée.
Ceci dit pour éviter de multiplier les variables globales si tu dois avoir plusieurs gestions de signaux et afin de mieux isoler cette gestion, tu pourrais construire une enveloppe C++ à tes signaux en passant par un std::function (ou boost::function). Ceci te permet de passer ensuite des objets plus évolués à ton enveloppe : lambda, std/boost::bind, etc.
Citation:
Envoyé par 3DArchi
Pour faire communiquer des process entre eux, il y'a aussi les IPC (pipe,fifo, mémoire partagée, sémaphore)
http://www.linux-kheops.com/doc/man/...an5/ipc.5.html
http://developers.sun.com/solaris/ar...med_pipes.html
cela évite les variables statiques...
Pour de simples signaux un sémaphore avec les bonnes propriétés peut suffire.
Il m'est arrivé, par exemple, de faire bloquer un process à son démarrage sur un sempaphore pour qu'il attende qu'un autre process qui initialisait le système lui donne le "go" de départ.
Ne pas oublier que l'origine du sémaphore est de transmettre des signaux, ce n'est pas pas hasard que les sémaphore informatique ont ce nom.
http://www.anbg.gov.au/flags/semaphore.html
Non ce n'est pas pour faire de la communication entre thread (je fais ça avec des pipes), c'est pour intercepter le signal SIGPIPE qui peut survenir lorsqu'un socket est détruit pendant une communication. Et comme c'est pour l'embarqué, je n'ai pas envie qu'il plante mon programme, du coup je dois lui donner un traitant particulier.Citation:
Envoyé par 3DArchi
Finalement, je suis passé par un flag global et je définis la partie de code à l'endroit où peut survenir l'erreur. Un peu bidouille, mais bon ça marche !
tu peux ignorer le sigpipe en faisant:Citation:
Envoyé par syl1405
Ensuite tu peux détecter que le lien est rompu en gérant les statut de retour des fonctions send/recv/....Code:
2
3
4
5
6/* Ignore the SIGPIPE signal */ struct sigaction action_pipe; memset(&action_pipe, 0, sizeof(action_pipe)); action_pipe.sa_handler=SIG_IGN; sigaction(SIGPIPE, &action_pipe, NULL);
recv et send retournent -1 en cas d'erreur et positionne un errno que tu peux interpréter.
Ensuite il est possible de désactiver certains signaux au niveau des socket avec setsockopt mais je ne sais pas si c'est très portable d'un système à l'autre.
Oui oui, c'est exactement ce que j'ai fini par faire, ça répond au traitement que je voulais :ccool:.Citation:
Envoyé par jabbounet
Hmm ... je n'avais pas vu ça. J'utilise setsockopt() pour mettre des timers sur les sockets mais j'ai pas creusé plus l'idée sachant que je savais intercepté SIGPIPE :)Citation:
Envoyé par jabbounet
Merci à tous pour vos réponses.
Ce serait SO_NOSIGPIPE pour setsockopt, je l'ai vu sur des page de man pour solaris et mac os mais pas sur celle linux :calim2:
par contre pour send tu as un champ flag avec lequel tu peux jouer, en positionnant MSG_NOSIGNAL par exemple.
C'est dommage, je suis justement sous Linux :) ...Citation:
Envoyé par jabbounet
Ah ça c'est vraiment bien, ça économise des lignes et ça fait propre :) Merci beaucoup pour cette info jabbounet !Citation:
Envoyé par jabbounet