软件事件在内部如何工作？
我是计算机科学专业的学生，了解了计算机程序运行时“幕后”发生的许多基本概念。但最近我意识到我不明白软件事件如何有效地工作。
在硬件中，这很容易：组件发送中断请求，而不是处理器“忙于等待”查看是否发生了某些情况。
但是，例如，在鼠标悬停事件中，这是如何工作的呢？我的猜测如下：如果鼠标发送信号（“移动”），操作系统计算其新位置p，然后检查屏幕上正在绘制什么程序，告诉程序位置p，然后程序本身检查什么对象位于 p，检查是否有任何事件处理程序与该对象关联并最终触发它们。
这对我来说听起来效率非常低，因为一个微小的鼠标移动就相当于大量的 cpu 上下文切换（我了解到这是相对昂贵的）。还有数十个后台应用程序可能也想做自己的事情。
我的直觉在哪里失败了？我意识到，即使是“慢速”500MHz 处理器每秒也会执行 5 亿次操作，但对于这样一个简单的事件来说，工作量仍然太大。
提前致谢！
I am a student of Computer Science and have learned many of the basic concepts of what is going on "under the hood" while a computer program is running. But recently I realized that I do not understand how software events work efficiently.
In hardware, this is easy: instead of the processor "busy waiting" to see if something happened, the component sends an interrupt request.
But how does this work in, for example, a mouse-over event? My guess is as follows: if the mouse sends a signal ("moved"), the operating system calculates its new position p, then checks what program is being drawn on the screen, tells that program position p, then the program itself checks what object is at p, checks if any event handlers are associated with said object and finally fires them.
That sounds terribly inefficient to me, since a tiny mouse movement equates to a lot of cpu context switches (which I learned are relatively expensive). And then there are dozens of background applications that may want to do stuff of their own as well.
Where is my intuition failing me? I realize that even "slow" 500MHz processors do 500 million operations per second, but still it seems too much work for such a simple event.
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
考虑像网络数据包这样的事件，因为它们通常由类似的机制处理。现在想想，您的鼠标每秒最多发送几百个数据包，每个数据包大约有 6 个字节。与现代机器的带宽能力相比，这根本不算什么。
事实上，你可以制作一个响应式 GUI，其中每次鼠标移动都会在大约 20 年前构建的硬件上发送一个网络数据包（86 字节，包括标头）：X11，Linux 和大多数其他 Unix 的基本 GUI 机制，可以做到这一点，在 80 年代末和 90 年代初经常以这种方式使用。当我第一次使用 GUI 时，它就是这样，虽然按照当前标准它并不是很好，但考虑到它在 20 MHz 机器上运行，它确实可用。
Think of events like network packets, since they're usually handled by similar mechanisms. Now think, your mouse sends a couple of hundred packets a second, maximum, and they're around 6 bytes each. That's nothing compared to the bandwidth capabilities of modern machines.
In fact, you could make a responsive GUI where every mouse motion literally sent a network packet (86 bytes including headers) on hardware built around 20 years ago: X11, the fundamental GUI mechanism for Linux and most other Unixes, can do exactly that, and frequently was used that way in the late 80s and early 90s. When I first used a GUI, that's what it was, and while it wasn't great by current standards, given that it was running on 20 MHz machines, it really was usable.
我的理解如下：
每个应用程序/窗口都有一个由操作系统中断填充的事件循环。
鼠标移动就会进入那里。
据我所知，所有窗口都有一个单独的队列/进程（自 3.1 以来的窗口）
每个窗口都有控件。
窗口会将此事件冒泡到控件。
控制器将确定该事件是否适合他。
因此，没有必要“计算”哪个项目在鼠标光标下绘制。
窗口和控件将确定该事件是否适合它们。
My understanding is as follows:
Every application/window has an event loop which is filled by the OS-interrupts.
The mouse move will come in there.
All windows have a separate queue/process by my knowledge (in windows since 3.1)
Every window has controls.
The window will bubble up this events to the controls.
The control will determine if the event is for him.
So its not necessary to "compute" which item is drawn under the mouse cursor.
The window, and then the control will determine if the event is for them.
您根据什么标准来确定它太多了？需要做多少工作就做多少。鼠标事件发生在毫秒范围内。将其获取到处理程序代码所需的工作可能以微秒为单位。这不是问题。
By what criteria do you determine that it's too much? It's as much work as it needs to be. Mouse events happen in the millisecond range. The work required to get it to the handler code is probably measured in microseconds. It's just not an issue.
你说得非常对 - 尽管鼠标事件以固定的速率发生（例如，Linux上的USB鼠标默认情况下每秒为你提供125次事件 - 这实际上并不是很多），并且操作系统或应用程序可能会进一步合并鼠标在发送处理之前时间或位置接近的事件
You're pretty much right - though mouse events occur at a fixed rate(e.g. an USB mouse on linux gives you events 125 times a second by default - which really is not a lot),, and the OS or application might further merge mouse events that's close in time or position before sending it off to be handled