Traitant de signaux dans une classe

**syl1405** · 10/08/2010, 09h32

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

**3DArchi** · 10/08/2010, 14h15

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 ?

**syl1405** · 10/08/2010, 14h48

Envoyé par 3DArchi

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

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

**white_tentacle** · 10/08/2010, 16h55

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

**3DArchi** · 11/08/2010, 07h11

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.

**jabbounet** · 11/08/2010, 09h12

Envoyé par 3DArchi

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.

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

**syl1405** · 11/08/2010, 09h15

Envoyé par 3DArchi

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.

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.

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 !