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.

[Johan.Mazel]

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.

[SoniX]

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)

[Johan.Mazel]

Merci beaucoup pour les informations.