All 15 Event Loop & Non-blocking IO questions
More in Event Loop & Non-blocking IO
What is the difference between concurrency and parallelism, and which one does Node.js's event loop actually provide by default? What is a callback queue (or task queue) in the context of the Node.js event loop, and how does it relate to the call stack? What does 'non-blocking I/O' mean, and how does a Node.js function like fs.readFile() achieve it compared to fs.readFileSync()? How does setImmediate() differ from process.nextTick() in terms of timing and typical use cases? What does it mean that Node.js's I/O is handled by libuv, and how does libuv abstract different operating systems' I/O mechanisms? What is the difference between synchronous and asynchronous versions of the same core Node.js API, using fs.readFile vs fs.readFileSync as an example, and when is the synchronous version actually appropriate? How would you measure how 'busy' the event loop is in a running Node.js process using a simple technique? What are the distinct phases of the Node.js event loop, and what kind of callbacks does each phase execute? What is 'event loop lag' (or 'event loop delay'), and how would you monitor it in a production Node.js application? What is the poll phase of the event loop, and under what specific conditions does it block waiting versus move on immediately?
Advertisement
Back to results for “OOP”
Node.js › Event Loop & Non-blocking IO

How does the event loop handle a large synchronous loop (like processing a huge array with a for loop), and what problem does this cause?

Intermediate

Answer

A synchronous for loop, no matter how large, runs to completion entirely within a single pass of the event loop, without yielding control back at any point -- during that entire time, the event loop cannot process any other pending callbacks, timers, or incoming I/O events, meaning every other concurrent request or scheduled task is completely blocked and delayed until the loop finishes, regardless of how many CPU cores the machine has.
// This blocks the event loop entirely until the loop completes
for (let i = 0; i < 100000000; i++) {
  result += computeExpensiveValue(i);
}
// No other request can be handled by this process during this entire loop
Real-world example A single API request that accidentally triggered a synchronous loop processing millions of records caused every other concurrent user's request to that same server instance to hang until the loop finished, illustrating why CPU-bound work needs to either be chunked, moved to a worker thread, or handled differently entirely.

Common follow-ups: How would you refactor this large synchronous loop to avoid blocking the event loop, using either chunking or a worker thread?;Does running multiple cluster workers actually solve this specific problem, or does it just limit its blast radius to one worker?

Clustering & Worker Threads;Performance Optimization & Profiling
All 15 Event Loop & Non-blocking IO questions