The Event Loop explained | NodeBook

[giscus[bot]]

The Event Loop explained

Learn and Master the complex parts of the Node.js Runtime. From V8's Turbofan optimizer to production deployments. Each chapter includes hands-on labs, real-world examples, and performance insights. The definitive guide to becoming a Node.js expert.

https://www.thenodebook.com/node-arch/event-loop-intro

[zgy03916618421]

Where are Macro queue and Micro queue? at V8 or libuv?

[ishtms]

@zgy03916618421 The microtask queue is indeed part of V8 for things like Promises. The macrotask queue is managed by libuv for external events like timers and file I/O. Both are important for the event loop though, which processes one macrotask and then immediately empties the entire microtask queue in each cycle (assuming the callstack is empty).

[gebsh]

The order of operations is always:

1. Execute the current macrotask.
2. Drain the entire nextTick queue.
3. Drain the entire Promise Jobs queue.
4. Okay, now we can proceed to the next macrotask.

The nextTick queue and the Promise Jobs queue are a bit more interleaved than this list suggests. Consider this example:

const process = require("node:process");

Promise.resolve().then(() => {
    setTimeout(() => console.log("1"));
    process.nextTick(() => console.log("2"));
    Promise.resolve().then(() => console.log("3"));
});

process.nextTick(() => {
    setTimeout(() => console.log("4"));
    process.nextTick(() => console.log("5"));
    Promise.resolve().then(() => console.log("6"));
});

Based on the steps above, you might expect the order of logs to be 5, 6, 3, 4, 1, 2, since the list says that after all Promise Jobs we loop back. However, this code prints 5, 6, 3, 2, 4, 1, so a nextTick job can be executed after Promise Jobs but before the next macrotask.

In the above example, it might be apparent because the context is explicitly given by nesting jobs, but it might be surprising when switching from CJS to ESM as there the context is implicit: Node processes ESM as part of the microtask queue. In fact, you can change the order of logs in the example from the A Complex Execution Order Analysis section just by switching the module system. If you replace the require() call and __filename with the import statement and import.meta.filename respectively, the logs change from 1, 9, 4, 3, 2, 5, 7, 8, 6 to 1, 9, 3, 4, 2, 5, 7, 8, 6. Perhaps it'd be worth putting this detail into a call-out or mentioning it explicitly?

[ishtms]

Thanks @gebsh, this is interesting. I've hardly written code like that, but it's worth looking into it. I'll do a thorough review of that section.

I think "always" wasn't the correct word choice in that section - it is a generalized/simplified sequence that would help readers to reason about and will apply 99% of that time.