WaitHandle.WaitOne pas vraiment bloquant [Résolu]

Messages postés
1163
Date d'inscription
vendredi 23 juillet 2004
Statut
Membre
Dernière intervention
21 octobre 2010
- - Dernière réponse : leprov
Messages postés
1163
Date d'inscription
vendredi 23 juillet 2004
Statut
Membre
Dernière intervention
21 octobre 2010
- 30 mars 2009 à 09:34
Bonjour,

Bon le soucis va pas être simple à expliquer....
Mon appli utilise un composant externe qui est initialisé au démarrage. Durant cette initialisation, le composant fait un WaitHandle.WaitOne. Ce WaitHandle.WaitOne (selon la stacktrace) dépile les évènements en attentes (fait un application.DoEvents? ou alors c'est la transition vers le code natif qui autorise à dépiler les events? en tous cas je le vois pas dans reflector). Hors, je peux recevoir des messages IPC. Donc, il m'arrive de recevoir et traiter ces messages IPC pendant le boot de mon appli, pendant le waitone, sur mon thread principal qui est censé être bloqué....
Bref, y'a-t-il un moyen de désactiver le traitement des events sur une portion de code (sans les perdre, evidemment. Juste pour qu'ils ne soient pas traités a un endroit ou le thread n'est pas censé avoir la main) pour éviter ce soucis? ou est ce que je dois gérer le cas a la main en mettant les events de coté tant que mon appli n'a pas finie de booter?
Afficher la suite 
A voir également:

2 réponses

Meilleure réponse
Messages postés
6352
Date d'inscription
samedi 1 juin 2002
Statut
Modérateur
Dernière intervention
2 août 2014
74
3
Merci
Salut,

Il me semble effectivement avoir lu un truc autour de ce sujet chez Chris Brumme. Le mécanisme de traitement des messages ne serait effectivement pas totalement bloqué.

/*
coq
MVP Visual C#
CoqBlog
*/

Dire « Merci » 3

Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire

Codes Sources 197 internautes nous ont dit merci ce mois-ci

Commenter la réponse de cs_coq
Messages postés
1163
Date d'inscription
vendredi 23 juillet 2004
Statut
Membre
Dernière intervention
21 octobre 2010
13
3
Merci
Effectivement Coq, je suis allé sur son blog, et il explique ca....Le passage le plus explicite à ce sujet, si ca interesse du monde :

Managed blocking includes a
contentious Monitor.Enter, WaitHandle.WaitOne, WaitHandle.WaitAny,
GC.WaitForPendingFinalizers, our ReaderWriterLock and Thread.Join.  It also includes anything
else in FX that calls down to these routines.  One noticeable place where this happens is during
COM Interop.  There
are pathways through COM Interop where a cache miss occurs on finding an
appropriate pUnk to dispatch a call.  At those points, the COM call is forced down a slow
path and we use this as an opportunity to pump a little bit.  We do this to allow the
Finalizer thread to release any pUnks on the current STA, if the application is
neglecting to pump.

Dire « Merci » 3

Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire

Codes Sources 197 internautes nous ont dit merci ce mois-ci

Commenter la réponse de leprov