Discussion :

[stephane.julien]

Bonjour,

J'ai une application qui travaille sur le principe des événements. Je peux la démarrer en mode console, service ou WinForm. Il y a environ 7 événements qui se suivent pour traverser les couches de l'application. Un thread est finalement lancé lorsque toutes les couches sont traversées.

Le thread principal doit donc principalement traiter les événements pour lancer des threads. Après un certain temps d'utilisation, un core de mon serveur s'emballe et les temps de réponse deviennent longs. Je soupçonne la pile d'événement qui n'est plus traitée ou qui est engorgée.

Je fais maintenant appel à Application.DoEvents(), mais pour m'assurer, j'aimerais savoir le nombre de messages dans la pile.

Y a-t-il un moyen de le savoir ? Y a-t-il un moyen d'optimiser ce traitement ? (mon processus est en priorité haute)

Merci d'avance !

[Nathanael Marchand]

Première question: on parle de quoi comme events? On parle d'events avec des abonnements genre myClass.OnEventFired += MyEventHandler ? De ManualResetEvent?
Seconde question: Si c'est le premier cas, pourquoi utiliser Application.DoEvents ? Qui n'a strictement aucun rapport! D'ailleurs pourquoi l'utiliser tout court? Ceci n'a d'interet que dans un contexte Winform. Dans une console ou un service, étant donné qu'il n'y a pas d'interface graphique, ca n'a pas de sens.

Bref c'est flou

[stephane.julien]

Il s'agit d'événements de style myClass.Event += MyEventHandler.

En cherchant comment sont traitées les piles de messages, je suis tombé sur Application.DoEvents(), mais je suis conscient qu'il s'agit de méthodes WinForms. Etant donné que je suspecte un engorgement de la pile de messages, je me suis dit que c'était peut-être une solution. Ce n'est apparemment pas le cas ? Je pensais que la pile des événements était la même pour les événements graphiques WinForm et les événements myClass.Event += MyEventHandler...

[theMonz31]

Salut

quand tu fais MyMethode.event+=....

Tu ne fais qu'enregistrer ta fonction (de droite) dans la liste des fonctions appelées lors du déclenchement de l'évènement associé.

A moins de faire un appel asynchrone, quand tu lèves ton évènement, toutes les fonctions de la liste sont appelées les unes après les autres. Il n'y a donc AUCUNE raison valable pour qu'elles ne soient pas appelées. L'appel étant synchrone par défaut lors du déclenchement d'un event, si une des méthodes "bloque", les autres ne seront pas appelées.

Il n'y a donc RIEN à dépiler...

Peut-être que si tu nous expliques la raison de cette question et du problème sous-jacent, nous pourrons t'éclairer en vue de trouver une solution (sauf si ma réponse résout ton problème)

[Bluedeep]

Il s'agit d'événements de style myClass.Event += MyEventHandler.

En cherchant comment sont traitées les piles de messages, je suis tombé sur Application.DoEvents(), mais je suis conscient qu'il s'agit de méthodes WinForms. Etant donné que je suspecte un engorgement de la pile de messages, je me suis dit que c'était peut-être une solution. Ce n'est apparemment pas le cas ? Je pensais que la pile des événements était la même pour les événements graphiques WinForm et les événements myClass.Event += MyEventHandler...

Apparemment tu fais un salmigondi avec les messages windows (et pas winforms) traités via la pompe à message, sur lesquel s'applique la méthode DoEvents et les Event de tes classes qui n'ont pas grand chose à voir la dedans (même si certains Event comme le "Click" sont traités via la pompe à message).

De plus, comme mentionné par Nathanael Marchand, les messages de la "pompe à message" n'ont de sens que dans le cadre d'une application Windows (donc, pour toi, avec des Winforms), le concept étant étranger à une application console, et, à plus forte raison, à un service.

Bref, merci d'être plus clair, car là c'est couleur fourmi.

[stephane.julien]

La raison de mon POST est le ralentissement de mon application de manière aléatoire, mais très flagrante. La seule piste que j'ai pour l'instant quant au ralentissement, c'est un core qui sature complètement. Je soupçonne le thread principal. Par contre je ne sais pas pourquoi il sature. Charge CPU plus élevée et taille mémoire relativement identique.

Mon application s'enregistre à un dll externe d'un fournisseur dont je dois taire le nom. Il s'agit d'une dll faite pour .Net et l'enregistrement à son événement est aussi de style "+=". J'en avais pour l'instant une instance pour 160 listeners. Vu que ces événements sont certainement synchrone (je pensais le contraire), j'ai maintenant créé 32 instances de la dll externe (selon la configuration de ma machine). Maximum 10 listeners par instance de classe de la dll externe. Le nombre de threads a explosé (24->130), et il faut attendre... C'est peut-être une bonne piste.

[stephane.julien]

C'était bien la solution. L'appel d'événements par la méthode "+=" fait bel et bien des appels synchrone. C'est ce qui explique qu'un seul thread de mon application saturait. Maintenant c'est beaucoup mieux réparti !

Merci theMonz31