首先，如果事件源自硬件输入，操作系统如何检测这些事件？这是通过轮询还是通过 BIOS 实现的？那么 BIOS 将如何捕获这些事件呢？轮询？他们不能使用 API，因为它与硬件交互，或者他们可以吗？
其次，操作系统是否会将这些事件沿链向上传递，例如，将它们传递给更高级别的编程语言（如 javascript）的浏览器？
第三，是否所有事件驱动模型最终都依赖轮询机制来检测 OS/BIOS 级别的事件？如果是这样的话，我们能否在事件驱动编程中拥有一个真正的“推送”系统？
【问题讨论】：
标签： javascript google-chrome events operating-system
冒着过于简单化的风险，如今大多数事件都是从中断开始的。硬件触发 CPU 中断，该中断调度到中断处理程序。
然后中断处理程序决定如何处理它们。
如果一个进程以某种方式注册以收到中断通知，则可能发生两件事：
操作系统可以触发软件中断。这会中断进程的正常运行并调用该进程已声明处理“事物”的函数。一个进程通常可以有多个函数处理不同的中断。
操作系统可以创建添加到事件队列的事件。该进程从队列中读取数据以确定正在发生的事情（MS-Windoze/X Windows 编程模型）。
事实上，Windoze 使用了这两种机制。底层 NT 系统被设计为使用软件中断（使用演示管理器 UI）。当Windoze 3 起飞时，M$ 切换到隐藏底层软件中断系统的WIndoze 界面
轮询可能用于某些类型的设备，但这种情况越来越不常见。在过去，您必须反复轮询操纵杆以确定其位置。飞行模拟必须反复轮询操纵杆以确定前进的方向，为此，它必须轮询多次。
因此，通常的顺序是操作系统获得中断 > 操作系统处理中断 > 操作系统创建队列条目 > 应用程序从队列中挑选条目。
【讨论】：