Process handler et classes en C++

Bonjour
Je cherche � cr�er une librairie/API en C++ pour cr�er des process dont l'ex�cution sera pilot�e par d'autres processus via des signaux. Je veux pouvoir lancer plusieurs processus et les arr�ter ind�pendamment.

J'utilise la fonction suivante : signal(SIGUSR1, CaptureProcess::handler) qui est issue de l'API C standard, pour assigner un handler � la r�ception d'un signal.
Cet handler est ensuite sens� aller modifier les attributs d'une classe ce qui influera sur l'ex�cution des fonctions de celle-ci.

Il semble que ce handler ne puisse malheureusement pas �tre d�finie autrement que par une m�thode statique dans la classe.
Cela pose un probl�me dans la mesure o� cela m'emp�che de piloter l'ex�cution de chaque thread ind�pendamment car je ne peux pas acc�der � des attributs de la classe qui ne soit pas statique.

Est-il possible d'assigner une m�thode de ma classe comme handler via la fonction signal (ou une autre m�thode) ?

Une autre solution consisterai � cr�er une structure de donn�es statique (via un vector par exemple) qui contiendrait l'ensemble des processus de conna�tre leur �tat courant. Chaque processus irait alors lire son �tat dans dans cette structure et piloterai son ex�cution en cons�quence. Cette solution me semble cependant un peu lourde � mettre en place en particulier au niveau du contr�le de l'acc�s concurrent � cette structure de donn�e.

Mes questions sont donc : existe-t-il une solution � mon probl�me au niveau du handler ? et est-ce que ma seconde solution est viable ?

Merci d'avance pour l'aide.

Essaie avec la fonction POSIX sigaction() plut�t que l'antique fonction standard signal().

De l'ext�rieur, tu ne peux pas adresser un thread particulier de ton process. Donc dans tous les cas, tu auras un thread "au pif" r�veill�...

Plut�t que des signaux, ce qui est quand m�me super bas niveau et merdique, regarde du c�t� des IPC, ou de dbus.

Citation:

---

Envoy� par white_tentacle

De l'ext�rieur, tu ne peux pas adresser un thread particulier de ton process. Donc dans tous les cas, tu auras un thread "au pif" r�veill�...

Plut�t que des signaux, ce qui est quand m�me super bas niveau et merdique, regarde du c�t� des IPC, ou de dbus.

---

Le but n'est pas de piloter des threads � l'int�rieur d'un autre process, mais plusieurs process � partir d'un seule et m�me autre process.
Et dans ce cas, avec les pid, je peux parfaitement envoyer des signaux � un process en particulier.

EDIT :
Je viens juste de tenter d'utiliser sigaction et de la m�me fa�on que pour signal, on ne peut utiliser que des fonctions statiques.
Cela ne r�sout pas vraiment le probl�me et ne fait que le d�placer.
Merci quand m�me pour le conseil. :)

Citation:

---

Le but n'est pas de piloter des threads � l'int�rieur d'un autre process, mais plusieurs process � partir d'un seule et m�me autre process.

---

Au temps pour moi, j'ai lu un peu trop en diagonale.

Je maintiens quand m�me ce que j'ai dit, avec des signaux uniquement, tu vas beaucoup t'emmerder.

Si tu ne veux pas passer par quelque chose d'aussi haut-niveau que dbus, regarde au moins du c�t� des IPC, c'est standard et quand m�me plus puissant que juste des signaux.

Regarde aussi du c�t� de la shared memory (je pense � la liste des processus notamment, ce truc l� devrait �tre stock� dans une shared memory, sinon, tu es � peu pr�s s�r qu'elle va se d�synchroniser entre tes diff�rents processus).

En fait, mes besoins sont tr�s basiques : dans un premier temps, je veux juste piloter l'arr�t de chaque processus individuellement, dans un second temps, je voudrais aussi modifier quelques param�tres dans le fonctionnement des processus.

Je pr�f�re effectivement eviter l'utilisation d'une API trop haut-niveau car j'ai un gros besoin de rapidit� aux niveau des process cr�es.

Le plus adapt� semble donc �tre une shared memory avec un s�maphore qui g�re son acc�s, les deux �tant des attributs static de ma classe.
La shared memory contiend un vector avec pour chaque pid, diff�rentes valeurs indiquant son �tat ou certains param�tres. Les processus vont ensuite chacun v�rifier leurs �tats/leurs param�tres dans la shared memory.
Les processus acc�dent ensuite � leur pid via une fonction comme getpid() de l'API C standard. Et en utilisant ce pid, ils actualisent leur �tat/leurs param�tres via la shared memory.
On peut �ventuellement concevoir que cette actualisation d'�tat/param�tre se fait sur r�ception d'un signal. Mais dans ce cas-l�, on retombe sur la premi�re question de mon premier post.
Si on utilise pas de signal, cela oblige � faire une v�rification p�riodique qui ne sera pas tr�s efficace.

Est-ce que ce sch�ma de fonctionnement vous semble viable ?

Citation:

---

Je pr�f�re effectivement eviter l'utilisation d'une API trop haut-niveau car j'ai un gros besoin de rapidit� aux niveau des process cr�es.

---

Les IPC, c'est quand m�me tr�s rapide, �a utilise de la shared memory derri�re. �ventuellement, tu peux regarder du c�t� de MPI aussi (au d�part fait pour faire du calcul distribu�). Tr�s rapide aussi.

Citation:

---

Est-ce que ce sch�ma de fonctionnement vous semble viable ?

---

Si on exclut le fait que tu ne peux pas mettre un vector en shared memory, et donc que tu devras g�rer ton propre tableau de processus, �a me semble viable.

Citation:

---

Si on utilise pas de signal, cela oblige � faire une v�rification p�riodique qui ne sera pas tr�s efficace.

---

Il me semble bien que tu peux utiliser des condition variables inter-process pour �viter les signaux.

En fait, les process vont capturer des paquets, ils devront donc �tre tr�s tr�s rapide pour ne rien rien rater.
Merci encore pour tous les conseils en tous cas.

Le probl�me que tu rencontres avec le handler de signal est classique d�s lors que tu doit fournir un pointeur de fonction 'callback' � une API C.

Le probl�me, c'est que les m�thode non statique C++ ne peuvent pas �tre utilis� avec de telle API.

La solution consiste � pass� par une m�thode statique qui va elle m�me rerouter l'appel vers une m�thode non statique en retrouvant le pointeur 'this' d'une mani�re ou d'une autre, toute la finesse �tant dans la fa�on de retrouver un 'this'.

Je te propose trois possibilit� pour retrouver 'this' :
* soit tu as plusieurs instances de la classe, et tu as besoin que chaque callback que tu enregistre dans l'API C rappelle la methode pour une instance particuli�re. Dans ce cas, il faut que l'API C te permette d'ajouter une donn�e 'utilisateur' avec le pointeur de la fonction (cas des fonction de cr�ation de thread comme 'pthread_create' par exemple). Cette donn�e 'user' sera ni plus-ni moins que ton pointeur this caster comme il faut. Ta m�thode statique appliquera le cast inverse pour retrouv� le pointer this et fera l'appel d'une m�thode classique dans le bon contexte d'objet. NB : ce n'est pas applicable � signal() car on ne peut pas y passer de param�tre user (ni pas sigaction() il me semble),
* soit tu as une seule instance qui doit recevoir la callback. Dans ce cas tu peux utilis� un singleton ou stocker un pointeur qlq part (en global, ou en statique dans la classe) qui permet � ta m�thode statique de retrouver le 'this' de l'objet sur lequel tu veux faire l'appel de la m�thode callback non statique.
* soit tu as plusieurs instance de la classe, chaque instance pouvant prendre en charge la callback. Dans ce cas, il te faut un genre de container accessible par le m�thode statique qui permettra � cette derni�re de choisir sur quel instance appeler la callback (le choix pouvant se faisant sur n'importe quel crit�re qui t'amuses)

Merci beaucoup pour les informations.