WaitHandle.WaitOne pas vraiment bloquant [Résolu]

leprov 1163 Messages postés vendredi 23 juillet 2004Date d'inscription 21 octobre 2010 Dernière intervention - 26 mars 2009 à 10:44 - Dernière réponse : leprov 1163 Messages postés vendredi 23 juillet 2004Date d'inscription 21 octobre 2010 Dernière intervention
- 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
cs_coq 6366 Messages postés samedi 1 juin 2002Date d'inscription 2 août 2014 Dernière intervention - 28 mars 2009 à 23:49
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
*/

Merci cs_coq 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 123 internautes ce mois-ci

Commenter la réponse de cs_coq
Meilleure réponse
leprov 1163 Messages postés vendredi 23 juillet 2004Date d'inscription 21 octobre 2010 Dernière intervention - 30 mars 2009 à 09:34
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.

Merci leprov 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 123 internautes 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.