My understanding of how asynchronous tasks are scheduled in JS
Please do correct me if I'm wrong about anything:
The JS runtime engine agents are driven by an event loop, which collects any user and other events, enqueuing tasks to handle each callback.
The event loop runs continuously and has the following thought process:
- Is the execution context stack (commonly referred to as the call stack) empty?
- If it is, then insert any microtasks in the microtask queue (or job queue) into the call stack. Keep doing this until the microtask queue is empty.
- If microtask queue is empty, then insert the oldest task from the task queue (or callback queue) into the call stack
So there are two key differences b/w how tasks and microtasks are handled:
- Microtasks (e.g. promises use microtask queue to run their callbacks) are prioritised over tasks (e.g. callbacks from othe web APIs such as setTimeout)
- Additionally, all microtasks are completed before any other event handling or rendering or any other task takes place. Thus, the application environment is basically the same between microtasks.
Promises were introduced in ES6 2015. I assume the microtask queue was also introduced in ES6.
My question
What was the motivation for introducing the microtask queue? Why not just keep using the task queue for promises as well?
Update #1 - I'm looking for a definite historical reason(s) for this change to the spec - i.e. what was the problem it was designed to solve, rather than an opinionated answer about the benefits of the microtask queue.
References:
- In depth: Microtasks and the JavaScript runtime environment
- HTML spec event loop processing model
- Javascript-hard-parts-v2
- loupe - Visualisation tool to understand JavaScript's call stack/event loop/callback queue interaction
- Using microtasks in JavaScript with queueMicrotask()
from What was the motivation for introducing a separate microtask queue which the event loop prioritises over the task queue?
No comments:
Post a Comment