javascript - 为什么同步监听子进程 “after” 产生它被认为是安全的？

Question

const subprocess = require("child_process").spawn("bad_command");
subprocess.on("error", _ => {
    console.info("Failed to spawn a subprocess.");
});

> node test.js
Failed to spawn a subprocess.

Construct one, and then listen to it.

虽然这被认为是在 Node 中监听 listenables^{(socket.io 套接字也这样做。)} 的正确方式。 js(或者可能是 Javascript)，我知道它可以毫无问题地工作，但我心里还是有点怀疑:“为什么它从不错过任何事件？”

---

我的理解是，事件可能异步发生在发射器创建后的任何时间。所以我想“为什么不在 收听 (.on) 之前发生呢？ 什么可以确保在监听之前、调用 .on 方法之前不会发生任何事件？”

还有两个实验，

const subprocess = require("child_process").spawn("bad_command");
setTimeout(_ => subprocess.on("error", _ => {
    console.info("Failed to spawn a subprocess.");
}), 10);

> node test.js
events.js:180
      throw er; // Unhandled 'error' event
      ^

Error: spawn bad_command ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:264:19)
    at onErrorNT (internal/child_process.js:456:16)
    at processTicksAndRejections (internal/process/task_queues.js:77:11)
Emitted 'error' event at:
    at Process.ChildProcess._handle.onexit (internal/child_process.js:270:12)
    at onErrorNT (internal/child_process.js:456:16)
    at processTicksAndRejections (internal/process/task_queues.js:77:11) {
  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn bad_command',
  path: 'bad_command',
  spawnargs: []
}

const subprocess = require("child_process").spawn("bad_command");
(function heavy_synchronous_task_that_takes_much_longer() {
    const Crypto = require("crypto");
    const buffer = Buffer.alloc(1_000_000);
    console.log(Date.now());
    for(let i = 0; i < 10_000; ++i) {
        Crypto.randomFillSync(buffer);
    }
    console.log(Date.now());
})();
subprocess.on("error", _ => {
    console.info("Failed to spawn a subprocess.");
});

> node test.js
1562646732809
1562646744631
Failed to spawn a subprocess.

我发现是确保它的东西，只有当监听器附加是同步的(我猜时间无关紧要。)，但我无法理解幕后发生的事情，因为代码本身并没有告诉我任何关于原因的信息。

我相信有人可以给我一个很好的语言规范或引擎实现方面的解释。

Answer 1

错误事件在进程退出时发出，由“nextTick”函数处理(参见第 1140 行 here)。

nextTick，如果我正在阅读 event loop documentation正确地，允许我们“通过使用 process.nextTick()，我们保证 [...] 始终在用户代码的其余部分之后和允许事件循环继续之前运行其回调。”