WaitHandle.WaitOne pas vraiment bloquant
Résolu
leprov
Messages postés
1160
Date d'inscription
vendredi 23 juillet 2004
Statut
Membre
Dernière intervention
21 octobre 2010
-
26 mars 2009 à 10:44
leprov Messages postés 1160 Date d'inscription vendredi 23 juillet 2004 Statut Membre Dernière intervention 21 octobre 2010 - 30 mars 2009 à 09:34
leprov Messages postés 1160 Date d'inscription vendredi 23 juillet 2004 Statut Membre Dernière intervention 21 octobre 2010 - 30 mars 2009 à 09:34
2 réponses
cs_coq
Messages postés
6349
Date d'inscription
samedi 1 juin 2002
Statut
Membre
Dernière intervention
2 août 2014
101
28 mars 2009 à 23:49
28 mars 2009 à 23:49
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
*/
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
*/
leprov
Messages postés
1160
Date d'inscription
vendredi 23 juillet 2004
Statut
Membre
Dernière intervention
21 octobre 2010
17
30 mars 2009 à 09:34
30 mars 2009 à 09:34
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.
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.
