使用COM的应用中，CoWaitForMultipleHandles能否替代WaitForMultipleObjects实现等待？

核心结论 #

在已初始化COM组件的线程中实现等待逻辑，首选CoWaitForMultipleHandles，绝大多数常规场景下单独使用该函数即可满足需求。

为什么不能直接使用WaitForMultipleObjects等普通等待函数 #

微软官方提示的风险本质是COM运行时的特性导致：如果线程初始化了STA（单线程套间）模型的COM，COM会为线程创建隐藏窗口用于处理跨套间调用、系统广播消息等。如果线程阻塞在普通等待函数上不处理消息，就会出现双向死锁：消息发送方等待窗口处理响应，你的线程等待内核对象触发，双方永久阻塞。
WaitForMultipleObjects不会处理任何线程消息，因此完全不适合在初始化过COM的线程中使用。

自己实现MsgWaitForMultipleObjects的坑 #

如果强行使用MsgWaitForMultipleObjects，在函数因消息触发返回后，你需要手动完成整套处理逻辑：

• 调用PeekMessage遍历取出线程消息队列中的所有消息
• 调用DispatchMessage分发消息，保证COM隐藏窗口的消息能被处理
• 处理完所有消息后才能重新进入等待状态
  这套逻辑的容错率极低，很容易因为遗漏COM特殊消息处理、重入规则处理等问题，还是出现死锁或者COM调用异常，不推荐自己实现。

CoWaitForMultipleHandles的适配性 #

CoWaitForMultipleHandles是COM官方提供的专门适配COM套间环境的等待函数，内部已经封装了所有必要的处理逻辑：

• 等待内核对象触发的同时，自动监听线程消息队列
• 自动处理COM相关的所有消息，包括STA套间跨调用请求、系统广播消息，不需要额外写消息处理逻辑
• 自动遵守COM重入规则，避免不符合预期的重入导致的业务逻辑错误
• 同时兼容STA和MTA套间模型，不需要根据线程套间类型做额外适配

补充说明 #

如果你的线程存在自定义窗口需要处理专属业务消息，可以在CoWaitForMultipleHandles返回消息触发的状态码后，新增自定义消息处理逻辑，处理完成后再重新进入等待即可，没有特殊需求的情况下不需要额外加任何处理代码。

内容的提问来源于stack exchange，提问作者AlexVB