什么是消息泵？
在这个线程 （大约一年前发布）中，讨论了在非交互式会话中运行Word的问题。 这个（相当强）的build议是不这样做的。 在其中的一篇文章中提到：“Office API都假设你在桌面上的交互式会话中运行Office，具有显示器，键盘和鼠标，最重要的是一个消息泵。 我不确定那是什么 （我已经用C＃编写了大约一年;我的其他编程经验主要用于ColdFusion。）
更新：
我的程序通过大量的RTF文件运行，以提取用于构build医疗报告编号的两条信息。 我没有试图弄清楚RTF中的格式化指令是如何工作的，而是决定在Word中打开它们，并从那里拉出文本（而不是真的启动GUI）。 偶尔，程序在处理一个文件的过程中被打断，并且留下了一个附加在该文件上的Word线程（我仍然需要弄清楚如何closures这个文件）。 当我重新运行程序时，当然我得到了一个使用该文件的线程的通知，并且我想打开一个只读副本？ 当我说“是”时，Word GUI突然从无处popup，开始处理文件。 我想知道为什么发生这种情况。 但它看起来像也许一旦对话框popup消息泵开始推动主要的graphics用户界面到Windows？
消息循环是本地Windows程序中存在的一小段代码。 它大致看起来像这样：
MSG msg; while(GetMessage(&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg); } GetMessage（）Win32 API从Windows检索消息。 你的程序通常花99.99％的时间在那里，等待Windows告诉它一些有趣的事情发生。 TranslateMessage（）是翻译键盘消息的帮助函数。 DispatchMessage（）确保窗口过程与消息一起被调用。
每个启用了.NET的程序都有一个消息循环，它由Application.Run（）启动。
消息循环与Office的相关性与COM相关。 Office程序是启用了COM的程序，这就是Microsoft.Office.Interop类的工作方式。 COM代表COM coclass处理线程，它确保在COM接口上进行的调用总是由正确的线程来完成的。 大多数COM类在registry中有一个registry键，它声明了他们的ThreadingModel，到目前为止最常用的（包括Office）使用“Apartment”。 这意味着调用接口方法的唯一安全方法是通过创build类对象的同一个线程进行调用。 或换句话说：到目前为止，大多数COM类不是线程安全的。
每个启用COM的线程都属于COM套件。 有两种，单螺纹公寓（STA）和multithreading公寓（MTA）。 必须在STA线程上创build一个公寓线程COM类。 您可以在.NET程序中看到这一点，Windows窗体或WPF程序的UI线程的入口点具有[STAThread]属性。 其他线程的公寓模型由Thread.SetApartmentState（）方法设置。
如果UI线程不是STA，则大部分Windowspipe道工程将无法正常工作。 值得注意的是拖放，剪贴板，Windows对话框，如OpenFileDialog。 和任何ActiveX控件和大多数COM服务器，如Office。
STA线程的一个硬要求就是它永远不要阻塞，而且必须抽取一个消息循环。 消息循环非常重要，因为这是COM用于将一个接口方法调用从一个线程编组到另一个线程。 虽然.NET使编组调用变得简单（例如Control.BeginInvoke或Dispatcher.BeginInvoke），但实际上这是非常棘手的事情。 执行调用的线程必须处于已知状态。 你不能任意中断一个线程，并强制它进行一个方法调用，这会导致可怕的重入问题。 一个线程应该是“空闲的”，而不是忙于执行任何改变程序状态的代码。
也许你可以看到引导的地方：是的，当程序执行消息循环时，它是空闲的。 实际的封送通过COM创build的隐藏窗口进行，使用PostMessage使该窗口的窗口过程执行代码。 在STA线程上。 消息循环确保这个代码运行。
“消息泵”是任何Windows程序的核心部分，负责将窗口消息分派到应用程序的各个部分。 这是Win32 UI编程的核心。 由于其普遍性，许多应用程序使用消息泵在不同模块之间传递消息，这就是Office应用程序在没有任何UI的情况下运行时会中断的原因。
维基百科有一个基本的描述 。
John正在谈论Windows系统（以及其他基于窗口的系统–X Window ，原始Mac OS ….）如何通过消息系统实现使用事件的asynchronous用户界面。
每个应用程序的幕后都有一个消息系统，每个窗口都可以将事件发送到其他窗口或事件监听器 – 这是通过向消息队列添加消息来实现的。 有一个主循环总是运行着看这个消息队列，然后把这个消息（或事件）分配给这个监听器。
维基百科文章Microsoft Windows中的消息循环显示了一个基本Windows程序的示例代码 – 正如您在最基本的层面上看到的，Windows程序只是“消息泵”。
所以，把它们放在一起。 Windows程序devise用于支持UI的原因不能充当服务，因为它需要始终运行的消息循环来启用UI支持。 如果按照所述将其作为服务实现，则将无法处理内部asynchronous事件处理。
在COM中 ，消息泵对公寓之间发送的消息进行序列化和反序列化。 公寓是一个可以运行COM组件的小型stream程。 公寓进来单线程和自由线程模式。 单线程单元主要是用于不支持multithreading的COM组件应用的传统系统。 它们通常与Visual BASIC（因为这不支持multithreading代码）和传统应用程序一起使用。
我想Word的消息泵要求来自COM API或应用程序的部分不是线程安全的。 请记住， .NET线程和垃圾收集模型不能很好地与COM开箱即用。 COM有一个非常简单的垃圾收集机制和线程模型，它要求你以COM的方式来做事情。 使用标准的Office PIA仍然需要你明确地closuresCOM对象引用，所以你需要跟踪每个创build的COM句柄。 如果你不小心的话，PIA也会在幕后创build一些东西。
.NET-COM整合本身就是一个整体，甚至还有关于这个主题的书籍。 即使在交互式桌面应用程序中使用COM API for Office，也需要跳过这些环节，并确保引用是明确发布的。
Office可以被认为是线程不安全的，因此您需要为每个线程单独使用Word， Excel或其他Office应用程序的实例。 你将不得不承担起始开销或维护一个线程池。 一个线程池将不得不被仔细testing，以确保所有的COM参考被正确释放。 即使启动和closures实例，也需要确保所有引用都正确释放。 未能点击我的，并跨越你的t在这里将导致大量死COM对象，甚至整个正在运行的Word实例泄漏。
维基百科build议这意味着该计划的主要事件循环 。
我认为这个第9频道的讨论有一个很好的简洁的解释：
窗口通信的这个过程由所谓的Windows消息泵实现。 将消息泵看作是能够在应用程序窗口和桌面之间进行合作的实体。
