【问题标题】:Why NodeJS block itself in The Poll Phase?为什么 NodeJS 在轮询阶段会阻塞自己?
【发布时间】:2019-03-08 09:44:35
【问题描述】:

来自docs

阶段概述

  1. timers:这个阶段执行由 setTimeout() 和 设置间隔()。
  2. 待处理回调:执行延迟到的 I/O 回调 下一个循环迭代。
  3. 空闲,准备:仅在内部使用。
  4. poll:检索新的 I/O 事件;执行 I/O 相关的回调(几乎所有 除了关闭回调,由计时器安排的回调, 和 setImmediate());节点会在适当的时候阻塞在这里。
  5. 检查: setImmediate() 回调在这里被调用。关闭回调:一些
  6. 关闭回调,例如socket.on('close', ...)。

在事件循环的每次运行之间,Node.js 检查它是否正在等待 对于任何异步 I/O 或计时器,如果有,则干净地关闭 没有。

我无法理解第四个项目符号。尤其是“node will block here when appropriate.”这一行

在什么情况下Node会阻塞自己,为什么?

【问题讨论】:

    标签: node.js


    【解决方案1】:

    正如section 中所解释的,轮询阶段计算它将阻塞和等待 I/O 的时间。 所以在这个阶段,如果在定时器阶段计算的时间阈值被超过,它会从定时器执行回调。

    如果没有超过计时器阈值并且轮询队列不为空,则事件循环将遍历其回调队列,同步执行它们,直到队列耗尽或达到系统相关的硬限制。

    如果轮询队列为空,则会发生另外两种情况之一:

    1- 如果脚本已被 setImmediate() 调度,则事件循环将结束轮询阶段并继续检查阶段以执行那些已调度的脚本。

    2- 如果脚本没有被 setImmediate() 调度,事件循环会等待回调加入队列,然后立即执行。

    【讨论】:

    • 达到了什么系统相关的硬限制?
    猜你喜欢
    • 2017-11-02
    • 1970-01-01
    • 1970-01-01
    • 2012-08-23
    • 1970-01-01
    • 1970-01-01
    • 2018-03-11
    • 1970-01-01
    • 2020-10-30
    相关资源
    最近更新 更多