Well, it does get "blocked" from the perspective of the caller who await-ed the read. That is, the caller gets paused at that point, thereby being "blocked".
However, since we're using the asynchronous fs.promises module, the runtime process itself (i.e. Node.js) is not blocked. As far as the event loop is concerned, Node.js will check if the file is available—in which case the promise resolves shortly after. Otherwise, it will periodically poll until the file is ready. In either case, the event loop continues to run, which is a good thing because this implies we may still poll and handle other promises and events for the meantime.
But if we use the synchronous APIs of the fs module instead (namely fs.readFileSync), that's when the event loop gets blocked. That is, no events will be polled and handled whatsoever. The loop is literally blocked until the requested file is ready.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Well, it does get "blocked" from the perspective of the caller who
await-ed theread. That is, the caller gets paused at that point, thereby being "blocked".However, since we're using the asynchronous
fs.promisesmodule, the runtime process itself (i.e. Node.js) is not blocked. As far as the event loop is concerned, Node.js will check if the file is available—in which case the promise resolves shortly after. Otherwise, it will periodically poll until the file is ready. In either case, the event loop continues to run, which is a good thing because this implies we may still poll and handle other promises and events for the meantime.But if we use the synchronous APIs of the
fsmodule instead (namelyfs.readFileSync), that's when the event loop gets blocked. That is, no events will be polled and handled whatsoever. The loop is literally blocked until the requested file is ready.