Discussion :

[Johan.Mazel]

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.

[M�dinoc]

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

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

[Johan.Mazel]

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.

[white_tentacle]

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

[Johan.Mazel]

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 ?

[white_tentacle]

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.

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.

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.