Application Console et Thread

Bonjour,

Voila j'ai besoin de mettre en place une application multithreadée qui se lancera et s'arrêtera automatiquement. Pas besoin d'IHM, la console me semble une bonne solution.

Mon application démarre donc sur une Sub Main, dans celle-ci j'instancie un System.Timers.Timer qui va vérifier la présence de travail à faire et lancer les Threads (utilisation de délégués) pour traiter le travail. Toute les 5 sec le Timer se lance et alimente les Threads, s'il n'y a plus de travail, le Timer ferme l'application (avec un gros "End", si il y a mieu je suis preneur) :roll:.

Le pb est : comment "bloquer" l'exécution de Sub Main pour ne pas que l'application se ferme ? Dans mon Sub Main, une fois Le timer instancié et activé je n'ai plus rien à faire et si je quitte sub Main l'application se ferme. :(

Actuellement je "bloque" avec un Console.ReadKey, j'aimerais savoir s'il existe mieux / plus propre.

Merci de votre aide !!! ;)

Ben, si ton appli ouvre une console, c'est qu'à priori elle a une interaction utilisateur, donc le Console.ReadKey, ben c'est pas si mal :D

Si tu n'as pas d'interaction utilisateur, tu n'as pas besoin de console, et tu fais un service, c'est fait pour cela. :D

En effet, si tu n'as pas besoin d'interaction utilisateur, on ne voit pas bien pourquoi tu devrais logger la machine sur laquelle s'exécute l'appli.

Si je ne bloque pas le programme va quitter sub main donc quitter l'application alors qu'il y a encore des threads de travail actifs.

Autre petite question : les accés à Console sont type Thread Safe ? En d'autre therme puis-je faire des Console.WriteLine("Blabla") depuis plusieurs thread sans que cela ne risque de poser de problème (Cross Thread Exception où autre chose de ce genre).

Merci de ta réponse rapide ;)

Citation:

Envoyé par MaelstroeM

Si je ne bloque pas le programme va quitter sub main donc quitter l'application alors qu'il y a encore des threads de travail actifs.

Ce n'est pas une obligation, tu peux faire une WaitAll sur des ManualResetEvent (ou n'importe quel autre objet de synchro) que tu auras alloué à chaque thread, et tu termines ton programme quand toutes les threads auront signalés leur Event.

Mais ce que je te disais, c'est que si on met une console, c'est que à priori on veut une interaction utilisteur (ici, le Console.ReadKey).

Si tu ne veux pas d'interaction utilisateur, tu ne mets pas de console, tu mets ton programme en service.

Code:

1 2 3 4 while not un_booleen 'traitement system.threading.thread.sleep(x) end while
le booléen te permet de sortir quand tu le mets à true
sleep arrete le thread pendant x ms

Citation:

Envoyé par sperot51

le booléen te permet de sortir quand tu le mets à true
sleep arrete le thread pendant x ms

L'utilisation d'un WaitAll sur un tableau d'EventWaitHandle me semble quand même un peu moins bricolo, non ?

Citation:

Envoyé par Bluedeep

L'utilisation d'un WaitAll sur un tableau d'EventWaitHandle me semble quand même un peu moins bricolo, non ?

ca dépend, dans les deux cas si c'est mal écrit ca déconne et c'est pas terriblement maintenable

m'enfin ca dépend de ce qu'il y a à faire avec ...

Citation:

Envoyé par sperot51

ca dépend, dans les deux cas si c'est mal écrit ca déconne et c'est pas terriblement maintenable...

C'est un fait, mais je ne pars jamais du postulat que les gens codent avec les pieds :D (dans les faits, il s'avére souvent que je fais preuve d'un incorrigible optimisme :mouarf: )

Bon je suis partie sur qq chose de ce genre :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 If args.Length >= 2 AndAlso UCase(args(1)) = "AUTO" Then Console.WriteLine("Démarrage en Automatique") Action_Start_Timer(False) End If While True Select Case CStr(Console.ReadLine()).ToUpper Case "START" : Action_Start_Timer(False) Case "FORCE START" : Action_Start_Timer(True) Case "STOP" : Action_Stop_Timer() Case "CANCEL" : Action_Cancel() Case "END" : Action_Cancel() : Exit While Case Else : Console.WriteLine("Commande inconnue") End Select Thread.Sleep(0) End While
Qui me permet de gérer qq commandes simples.
Si dans le Elapsed du timer il ne trouve plus de travail a envoyer il ferme l'application avec un "End", je n'ai rien trouvé de propre pour router l'information de fermeture au Sub_Main.

Mes threads de travail sont géré avec des délégués (voir exemple Prime Number Calculator dans MSDN) et sont alimentés par le System.Timers.Timer qui se lance périodiquement.

Par contre je suis curieux de voir ton system de "EventWaitHandle", bien que j'ai croisé ça dans MSDN quand je me suis interrésé au multiThreading je n'ai pas creusé dans ce sens.

Si j'ai bien compris je peux utiliser un EventWaitHandle , dans le Sub_Main j'attends avec WaitOne que le Timer signal via Set() qu'il n'y a plus de travaux et donc que je peux quitter l'application ?

Dans tous les cas je vous remercie pour votre aide.