Windows 事件是顺序处理还是并行处理？答案

【问题标题】：Are windows events handled sequentially or in parallel?Windows 事件是顺序处理还是并行处理？
【发布时间】：2014-06-13 18:20:16
【问题描述】：

我一直认为应用程序事件队列中的事件是按顺序处理的，但由于一些其他方式很难解释我的应用程序中的不当行为，我需要问：不同事件的事件处理程序是否会并行运行?我正在使用wxWidgets 及其事件处理机制，以防万一；我也确实将多线程用于其他目的，带有“主”和“工作”线程（wxThreadHelper），并且印象中通常的事件只能由 - 单 - 主线程 - 和单 -螺纹。有人可以确认一种方式吗？

编辑：我说的是 Windows 用语中的 message（WM_PAINT、WM_KEYDOWN 等），但我说的是 events 因为 wxWidgets 命名约定（wxPaintEvent 等）。对困惑感到抱歉。事实上，我使用 wxWidgets 机制而不是 Windows 自己的机制甚至可能很重要；例如也许 wxWidgets 单线程弹出消息并多线程将它们分派到 OnFoobarHandler() ，反之亦然 - 我不知道（尽管我以为我知道了）。

【问题讨论】：

你在谈论消息吗？ Events 仅用于在事情发生时发出信号，这些事情是什么纯粹是应用层的决定。
我认为他在谈论 Windows 消息（即 GetMessage、DispatchMessage、PostMessage、SendMessage 等...）
Hagen - 在我发布长答案之前，您能否澄清事件队列的含义并发布相关代码示例？您可以随时调用 GetThreadId() API 来确定您的回调发生在哪个线程上。
在某些情况下，事件可以以可重入的方式处理。这确实很危险，看起来就像真正的并发。

标签： windows multithreading wxwidgets

【解决方案1】：

事件仅在主 UI 线程中处理。只有它有一个事件循环，所有的处理程序都从它调用，因此在同一个线程上执行。

没有魔法。

【讨论】：

嗯，在 Arthur C. Clarke 的意义上有魔法，直到我发现我的错误：碰巧一个函数调用导致wxASSERT，默认情况下向用户显示一个对话框。但是我的程序作为服务运行，因此没有 GUI。似乎在这种情况下，事件处理函数退出时没有可捕获的异常，也没有（！）从堆栈中删除对象；这就是最初让我看起来像同时处理两个事件的原因。在我的应用程序类中覆盖 OnAssertFailure 可以解决问题（并允许找到 wxASSERT 的真正原因）。
这对我来说似乎很可疑。也许某些东西（在您的代码内部或外部）会吃掉 Windows（即 SEH）异常。因为默认的断言处理程序要么正常返回（例如，在禁用断言对话框的发布版本中）或死亡（例如，如果它被重新输入），所以它无法解释你所看到的。