2010-10-11 18 views
2

Lors de la création d'un nouveau thread STA pour héberger un composant COM STA, il est de la responsabilité de ce thread de pomper les messages Windows liés à COM. D'après ce que j'ai pu rassembler, certaines primitives de threads .NET intégrées telles que lock (Monitor.Enter) le feront pour vous en attendant que l'objet soit libéré par un autre thread. Une autre façon de créer des messages COM .NET pompe pour vous que j'ai vu est d'utiliser .Join().Quelles sont les opérations de threading bloquantes dans .NET qui gèrent les messages COM lorsqu'elles sont bloquées?

Où puis-je trouver une liste complète des primitives de thread intégrées avec ce comportement? Souhaitez-vous attendre sur un WaitHandle? Qu'en est-il de WaitAny(), ou des nouvelles collections concurrentes dans .NET 4? Je suis incapable de trouver cela dans la documentation pour l'une des méthodes spécifiques.

Répondre

1

Cela peut être quelque peu inversé à partir de la source SSCLI20, bien qu'il soit daté. La fonction CLR principale qui implémente MsgWaitForMultipleHandles est DoAppropriateWait. De ce que je vois, il est utilisé par AutoResetEvent, ManualResetEvent et Semaphore mais pas par Mutex. Un inconvénient est que WaitHandle.WaitAny est correct à partir d'un thread STA mais WaitAll() génère une exception. Ouais, ceci n'est documenté nulle part ailleurs que quelques indices sur le blog de Chris Brumme. Vous ne pouvez pas supposer trop de ce que j'ai trouvé, tester cela pour être sûr.

+0

Très utile, merci! – SoftMemes