相关疑难解决方法(0)

我在网上搜索了一些关于阻止I/O和非阻塞I/O的技术细节,我发现有几个人说非阻塞I/O比阻塞I/O更快.例如,在本文档中.

如果我使用阻塞I/O,那么当然阻塞的线程当然不会做任何其他事情......因为它被阻止了.但是一旦线程开始被阻塞,操作系统就可以切换到另一个线程而不会切换回来,直到阻塞的线程有事情要做.因此,只要系统上有另一个需要CPU并且没有被阻塞的线程,与基于事件的非阻塞方法相比,不应该有更多的CPU空闲时间,是吗？

除了减少CPU空闲时间之外,我还看到了另外一个选项,可以增加计算机在给定时间范围内可以执行的任务数量:减少切换线程所带来的开销.但是怎么做呢？并且开销是否足以显示可衡量的影响？以下是关于如何将其工作的想法:

1. 要加载文件的内容,应用程序将此任务委托给基于事件的i/o框架,并传递回调函数和文件名
2. 事件框架委托给操作系统,该操作系统编程硬盘的DMA控制器以将文件直接写入存储器
3. 事件框架允许运行更多代码.
4. 完成磁盘到存储器的复制后,DMA控制器会产生中断.
5. 操作系统的中断处理程序通知基于事件的i/o框架有关文件被完全加载到内存中的信息.它是如何做到的？使用信号??
6. 当前在事件I/O框架内运行的代码完成.
7. 基于事件的i/o框架检查其队列并从步骤5中查看操作系统的消息,并执行它在步骤1中获得的回调.

它是如何工作的？如果没有,它是如何工作的？这意味着事件系统可以在不需要显式触摸堆栈的情况下工作(例如需要备份堆栈并在切换线程时将另一个线程的堆栈复制到内存中的真实调度程序)？这实际节省了多少时间？还有更多吗？

问题:与常规函数的return语句相比,是否存在(并且,如果是,在何种程度上)引擎运行时的计算开销以声明函数async和最终await？

async function foo() {
    var x = await bar(); // <--- bar() is non-blocking so await to get the return value
    return x; // the return value is wrapped in a Promise because of async
}

与

function foo() {
    var x = bar(); // <--- bar() is blocking inside its body so we get the return value
    return new Promise(resolve => { resolve(x); }); // return a Promise manually
}

背景:

由于Javascript(和Nodejs)采用异步方向,为什么他们不 …