软件事件在内部是如何运作的？答案

【问题标题】：How do software events work internally?软件事件在内部是如何运作的？
【发布时间】：2011-02-22 16:00:28
【问题描述】：

我是计算机科学专业的学生，并且已经了解了计算机程序运行时“幕后”发生的许多基本概念。但最近我意识到我不明白软件事件如何有效地工作。

在硬件中，这很容易：不是处理器“忙于等待”以查看是否发生了什么事情，而是组件发送中断请求。

但是这在例如鼠标悬停事件中是如何工作的呢？我的猜测如下：如果鼠标发送一个信号（“移动”），操作系统计算它的新位置 p，然后检查屏幕上正在绘制什么程序，告诉程序位置 p，然后程序本身检查什么对象位于 p，检查是否有任何事件处理程序与所述对象关联并最终触发它们。

对我来说这听起来效率非常低，因为鼠标的微小移动相当于大量的 cpu 上下文切换（我了解到这些切换相对昂贵）。然后有几十个后台应用程序可能也想做自己的事情。

我的直觉在哪里让我失望？我意识到即使是“慢”的 500MHz 处理器每秒也执行 5 亿次操作，但对于这样一个简单的事件来说，工作量似乎还是太大了。

提前致谢！

【问题讨论】：

小心“低效”之类的概念，因为效率总是相对的，当处理器的运行速度比我们快 6 到 9 个数量级时，关于什么是高效的直觉是不可信的。它有助于从数量上看待它。
...顺便说一句，即使处理器中的中断请求仍然是在微码级别通过忙等待来完成的。在微码状态机中有一个点，它查询中断请求行以查看是否应该启动中断序列。

标签： language-agnostic computer-science performance events

【解决方案1】：

想想网络数据包之类的事件，因为它们通常由类似的机制处理。现在想想，你的鼠标每秒最多发送几百个数据包，每个数据包大约 6 个字节。与现代机器的带宽能力相比，这算不了什么。

事实上，您可以在大约 20 年前构建的硬件上创建一个响应式 GUI，其中每个鼠标移动都会发送一个网络数据包（包括标头在内的 86 个字节）：X11，Linux 和大多数其他 Unix 的基本 GUI 机制，可以做到正是如此，并且在 80 年代末和 90 年代初经常以这种方式使用。当我第一次使用 GUI 时，它就是这样，虽然按照目前的标准它不是很好，但考虑到它在 20 MHz 的机器上运行，它确实是可用的。

【讨论】：

【解决方案2】：

我的理解如下：

每个应用程序/窗口都有一个由操作系统中断填充的事件循环。鼠标移动将进入那里。据我所知，所有窗口都有一个单独的队列/进程（自 3.1 起在 Windows 中）

每个窗口都有控件。窗口会将这些事件冒泡到控件中。控件将确定该事件是否适合他。

因此没有必要“计算”在鼠标光标下绘制的项目。窗口，然后控件将确定该事件是否适合他们。

【讨论】：

【解决方案3】：

您根据什么标准确定它太多了？它需要做的工作就足够了。鼠标事件发生在毫秒范围内。将其发送到处理程序代码所需的工作可能以微秒为单位。这不是问题。

【讨论】：

我认为他确切地要求对工作量进行一些“量化”，以了解它是否过多。（显然不是，因为它确实有效，但是当你有一些数字要查看时会更好）

【解决方案4】：

您说的非常对 - 尽管鼠标事件以固定速率发生（例如，Linux 上的 USB 鼠标默认情况下每秒为您提供 125 次事件 - 这确实不是很多），并且操作系统或应用程序可能进一步合并在时间或位置上接近的鼠标事件，然后将其发送以进行处理

【讨论】：