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.