在阅读Node时,定义说I/O模型是事件驱动的。这与多线程环境中的中断有什么不同?在多线程环境中,当I/O操作完成时,会生成一个中断,等待线程现在被推入read以运行状态。在Node中,基于I/O完成后引发的事件,回调处理程序被推送到事件队列。
为什么这两者是不同的?
发布于 2016-03-22 03:39:50
我不确定我是否理解这个问题,但我的理解是.
这两个概念是不同的,因为它们适用于不同层次的处理。事件的使用级别(系统/代码)高于中断,中断发生在较低级别(CPU)。因此,即使中断确实发生在CPU级别,nodejs也会抽象它们(使用单独的I/O线程),如果定义了回调,就会执行回调。像Java这样的多线程环境所做的是挂起和恢复线程。这与CPU级别的中断不一样.Java确实让程序员实现了这样的中断:
for (int i = 0; i < importantInfo.length; i++) {
// Pause for 4 seconds
try {
Thread.sleep(4000);
} catch (InterruptedException e) {
// We've been interrupted: no more messages.
return;
}
// Print a message
System.out.println(importantInfo[i]);
}但这与CPU中断或nodejs事件/回调完全不同。
尽管nodejs据说是单线程的,但它确实使用了多个线程,但是它只使用一个主线程,该线程的设计目的是在CPU上花费很少的时间,并将其他IO或CPU密集型任务传递给其他任务,这样就可以处理下一个(通常是http)请求。
一些参考链接:
multithreading.html
http://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html
Difference between interrupt and event
https://softwareengineering.stackexchange.com/questions/298493/nodejs-like-interrupt-handlers
https://stackoverflow.com/questions/36144913
复制相似问题