awaiting a promise is still asynchronous. When the runtime hits an await, it queues a micro-task at the end of the event loop to check if the result is ready and then continues executing the current set of instructions in the loop.
The microtask checks for the result and if it’s still not ready (either because the db is still working, or network delay) it schedules a new microtask and starts the next event loop, where it can continue serving requests or doing other work while waiting.
Once the db operation returns a value, and the microtask is run, it will continue the function where it was paused by the await.
Even if the promise returning function is synchronous, and returns a result immediately, the async function will be paused till the end of the event loop, where the microtask is scheduled.
Ah… Thanks for the info. How does one actually “block the event loop” then? Just with a heavy CPU-intensive function? I always assumed (incorrectly apparently) it was forcing waits on stuff synchronously.
Yeah, usually it’s when you do a large amount of data processing which blocks other requests from being served.
It’s not exactly blocking since it’s still doing work. At which point it’s better to offload the work into a web worker, worker thread or a child process.
You can also block the event loop with Node’s sync versions of functions, like fs.readFileSync.
Node will block the thread while waiting for the result