Discussion :

[masterx_goldman]

Bonjour tout le monde,

Je veux créer un service Windows qui gère plusieurs processus. La gestion des processus consiste à:

1) Lancer et Contrôler les processus :
+ Des processus doivent tourner de façon permanente tant que le service tourne(donc les relancer en cas d'arrêt imprévu ou que l'utilisateur les arrêtent)
+ Des processus doivent être lancé périodiquement à une date donné chaque jour
2) Arrêter tous les processus qu'il a lancé quand on arrête le service.

3) Faire d'autres tâches, après lancement des processus.

J'ai commencé par la méthode suivante: créer une liste d'objets, chaque objet représente un processus( pid, HANDLE obtenu après lancement,...) et je lance un thread pour le gérer, donc j'aurai N threads si j'ai N processus.
Je commence par une question sur le fondement de l'idée, ça vous paraît mal comme méthode ? Est ce que le nombre de threads devient gênant pour le pc quand il devient grand( exemple 100 threads ) ? Il vaut mieux faire un seul thread ?

Merci de donner vos avis

[Mac LAK]

Je commence par une question sur le fondement de l'idée, ça vous paraît mal comme méthode ? Est ce que le nombre de threads devient gênant pour le pc quand il devient grand( exemple 100 threads ) ? Il vaut mieux faire un seul thread ?

Sous Windows, un thread ne coûte pas grand-chose côté système... Encore moins s'il est bloqué sur un WFSO pour "attendre" qu'un processus se termine !

A mon avis, tes 100 processus seront nettement plus problématiques que les 100 threads de contrôle associés, bien que cela dépende en effet du boulot réellement effectué par les threads en question.

Si, par exemple, ils capturent et consignent un log de chaque processus, ça va devenir nettement plus coûteux que s'ils se contentent de le surveiller pour le relancer en cas de terminaison non prévue.