这怎么可能：而在WaitOne方法的OnPaint处理 [英] How is this possible: OnPaint processed while in WaitOne

问题描述

我有一个的ManualResetEvent 。在一个点上，我等待使用该事件的的WaitOne 。令我惊讶的是，我收到了一个的OnPaint 事件，而在的WaitOne 。这种情况经常了。

I have a ManualResetEvent. At one point, I wait on that event using WaitOne. To my amazement, I received an OnPaint event while in the WaitOne. This happens quite often too.

堆栈跟踪看起来是这样的：

The stack trace looks like this:

我理解的是，的WaitOne 将阻止当前线程，不会允许任何其他code，直到该事件触发执行。

I understood that a WaitOne would block the current thread and would not allow any other code to be executed until the event fires.

有人能解释发生了什么吗？

Could someone explain what happens here?

推荐答案

这是设计使然。 CLR的荣誉单线程单元（STA）的合同。的GUI应用程序的主线程是STA的需要Windows编程，在Main（）方法在[STAThread]属性保证了。

This is by design. The CLR honors the contract of a single-threaded apartment (STA). The main thread of a GUI app is STA as is required in Windows programming, the [STAThread] attribute on the Main() method ensures that.

硬的规则，它必须泵消息循环（如Application.Run），并不能阻止。阻止STA线程极有可能造成死锁时，后台线程使用任何COM单元线程对象。有许多人，剪贴板和web浏览器是常见的，你会在.NET程序遇到的问题。很多不太显眼的人，以及，作为.NET包装类。

Hard rules for an STA thread are that it must pump a message loop (like Application.Run) and can never block. Blocking an STA thread is highly likely to cause deadlock when background threads use any COM apartment threaded objects. There are many of them, the clipboard and WebBrowser are common ones you'll encounter in a .NET program. Many less visible ones as well, available as .NET wrapper classes.

在CLR确保阻塞不能抽消息循环，当你使用lock语句或致电同步类的wait方法导致死锁。或者的Thread.join（）。这个消息循环调度WM_PAINT消息，引发Paint事件来运行。

The CLR ensures blocking can't cause deadlock by pumping a message loop when you use the lock statement or call the Wait method of the synchronization classes. Or Thread.Join(). That message loop dispatches the WM_PAINT message, causing the Paint event to run.

您需要调整您的程序，以确保这不会导致出现问题。 pretty的重要关注不阻塞主线程的。这是很少需要的时候，你有，比方说，BackgroundWorker的类或Control.BeginInvoke（）在您的处置。对于某种奇怪的原因Mutex类并没有做这样的抽，这可能是另一种方式。虽然死锁潜伏在拐角处，如果你做的。

You need to restructure your program to ensure this doesn't cause a problem. Pretty important to focus on not blocking the main thread at all. It is very rarely needed when you have, say, the BackgroundWorker class or Control.BeginInvoke() at your disposal. For some kind of odd reason the Mutex class doesn't do this kind of pumping, that could be another way. Although deadlock is lurking around the corner if you do.

这篇关于这怎么可能：而在WaitOne方法的OnPaint处理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！