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