我有一个旧版 C++、MFC 应用程序，目前在 VS2005 中编译。
它有几个套接字连接，以及一个用户 GUI。
套接字在非 MFC 线程中终止，在这些后台线程中完成一些工作，然后将一条消息发布到 MFC 主队列，以便主应用程序可以注意到并执行适当的操作。请注意，对于每条套接字接收到的消息，都会向主线程发布一条消息。
产生的主线程动作通常每个只需要几分之一秒。
但是，如果我收到 大量 消息，GUI 可能会在一段时间内变得迟缓甚至无响应，因为主线程正忙于执行集成新数据任务而不是响应用户。
如果我能清楚地表达我的问题：有什么解决方案的建议，以便 GUI 在面对大量此类事件时保持响应？
【问题讨论】：
标签： mfc
如果您希望 GUI 完全优先于套接字工作，您可以使用 CWinApp::OnIdle 检查要在套接字上完成的工作。
【讨论】：
我自己的答案 - 不要太用力地扔东西！ :)
想法是将每条消息的一条消息发布到主线程分解为更分解的模型。
如果我有三个后台监听线程，那么我应该有三个后台队列，与主 MFC 事件队列分开。当我收到东西时，我会发布到 MFC 主线程；并在特定的后台队列中排队。
当 MFC 主线程处理该特定事件时，我可以对相应后台队列中接收到的部分或全部消息进行处理，如果我没有完全排空队列，那么我只需将消息重新发布到MFC 主线程，以确保我会再次醒来以完成工作。
这确保了 GUI 事件将以适当的速率发送，即使在从各种后台线程接收到高其他消息速率的情况下。
【讨论】：
您能否分析在您的 GUI/主线程中调用的代码。您确定需要在主/GUI 线程中进行处理吗？如果可能，将工作转移到另一个线程或调整正在完成的工作。
【讨论】：
与其试图在面对大量事件时保持 GUI 响应，您只需要确保它从一开始就不会收到如此大量的事件。
在典型的计算机上，屏幕仅以 60 FPS 的速度重新绘制，因此没有什么比这更快的了。对于用户而言，即使是 60 FPS 也仅对电影级别的内容才真正有意义。
对于典型的数据更新，10 FPS 是很快的——要感知这么多，您需要将数据总结为易于理解的几部分，并避免覆盖任何现有文本，这样它就不会变成模糊不清。
【讨论】：