事件驱动编程:回调与消息轮询

Question

作为一个OpenGL程序员，我一直在研究C++编程，并且看到了两种处理事件驱动编程的主要方法:消息轮询或回调函数。

• 我看到本机Win32API使用由DispatchMessage函数触发的回调函数。
• SDL (基于教程)也使用某种回调或类似回调的编程。
• GLFW也使用回调。
• SFML允许程序员在代码中的任何地方(通常在循环中)对单个消息进行轮询，从而形成消息循环。
• 基于我所看到的X窗口系统也使用消息轮询。

显然，由于事件系统存在于突出的环境中，因此每个系统都必须具有优势。我希望有人能告诉我每种方法的优缺点。我正在考虑编写一些程序，这些程序将在很大程度上依赖于事件驱动的编程，并且希望在选择哪条道路上做出最好的决定。

Answer 1

这还不完整，但我想到了几件事.

我只使用GL的3D，并没有做太多的方式，图形界面。事件轮询非常常见。更准确地说，在主呈现循环中轮询，该循环处理队列中的所有事件，然后转到呈现。这是因为，在收集所有事件并使用它们更新场景的3D状态之后，您将从零开始重新呈现每一帧。由于屏幕只能以有限的帧速率显示图像，所以在轮询期间睡眠也很常见，因为任何状态更新都要到很晚才会显示，即使它们的事件被触发得更早。

• 如果您要按照事件发生的情况进行处理，比如通过绘图进行部分处理，那么您就有了竞赛条件。处理这件事可能是不必要的仓促。
• 如果您有任何动画，那么您已经有一个循环和轮询是一个微不足道的成本，相比之下。
• 如果您的事件很少发生，那么您不需要经常重新绘制线程，因此线程活动和轮询是有点低效率的。
• 如果事情堆积在一起，你会为每一件事重新画一张图，那就太糟糕了。您可能会发现，与使用循环处理所有事件和呈现一次相比，您重新绘制的频率更高。

我认为轮询的主要问题是不受关注的非活动窗口。假设你最小化了你的GL应用程序。您知道它不会接收任何事件，所以轮询是无用的。在这件事上，绘画也是如此。

另一个问题是响应延迟。这对于在游戏中捕捉鼠标运动是非常重要的。只要您按正确的顺序轮询事件(输入、→、更新、→显示)，这通常是可以的。然而，vsync可以通过延迟帧的显示来扰乱时间。

Answer 2

我目前正在基于opengl和evdev.为linux创建轻量级图形用户界面库

第一个是在C中开发的，它启发我实现消息体系结构，灵感来自于管道用于多线程通信。

第二，在c++中，我只使用回调，但是linux中的c++堆栈是消息驱动的。

我的结论是，对于外围设备(例如:鼠标)，它可以比程序响应的速度更快地触发中断，您需要一个fifo层(通常是一个管道)来异步地在两个上下文之间进行通信。因此:消息只是多线程环境中的异步缓冲回调。

您也可以使用回调fifo来缓冲您的事件。但是，在线程之间组织变量并不总是容易的(信号量、锁定等)。使用消息作为唯一的进程间同步机制有助于清除这一点。