WaitHandle.WaitOne pas vraiment bloquant [Résolu]

Messages postés
1163
Date d'inscription
vendredi 23 juillet 2004
Dernière intervention
21 octobre 2010
- - Dernière réponse : leprov
Messages postés
1163
Date d'inscription
vendredi 23 juillet 2004
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 

Votre réponse

2 réponses

Meilleure réponse
Messages postés
6366
Date d'inscription
samedi 1 juin 2002
Dernière intervention
2 août 2014
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 95 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
Dernière intervention
21 octobre 2010
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 95 internautes nous ont dit merci ce mois-ci

Commenter la réponse de leprov

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.