Why is fs.readFile non-blocking but fs.readFileSync blocking?
fs.readFile delegates to libuv and returns immediately, letting the event loop process other requests while the file reads. The callback runs when the read completes. fs.readFileSync blocks the thread until the file is read, stopping all requests.
Verify This Answer
Cross-check this information using these trusted sources:
More FAQs in Real-World Event Loop Examples in Node.js
fs.readFile does not block: the main thread continues, other requests are processed while the file reads, and the callback runs when it completes. fs.readFileSync blocks: the event loop stops until the file is read. Promise.all runs three API calls in parallel instead of sequentially.
1, 4, 3, 2. Sync code runs first (1, 4), then microtasks (promise callback 3), then macrotasks (setTimeout callback 2). This demonstrates event loop order: sync, then microtasks, then macrotasks.
Three independent API calls awaited sequentially take 3 times the longest. With Promise.all, they run in parallel, taking only as long as the slowest. The event loop processes all three concurrently, demonstrating non-blocking I/O.
Still have questions?
Browse all our FAQs or reach out to our support team