Timers & Concurrency Control

The Event Loop Architecture: Macrotasks vs Microtasks

The JavaScript runtime processes operations through distinct scheduling queues:

1. Call Stack (Synchronous): Executes frames in LIFO order until empty.
2. Microtask Queue: Contains Promise reactions (.then, .catch, .finally), queueMicrotask, and MutationObserver callbacks. This queue is exhaustively drained immediately whenever the Call Stack becomes empty, as well as after every single individual macrotask callback.
3. Macrotask (Task) Queue: Contains timer callbacks (setTimeout, setInterval), DOM event listeners, and I/O callbacks.

Why Microtasks Inside Timers Preempt Subsequent Timers

Prior to Node.js v11, Node processed timers in a batch loop. However, the W3C HTML Living Standard and modern Node.js v11+ mandate that the microtask checkpoint is executed after every single macrotask callback. When timer-1 schedules micro-after-t1, that microtask drains immediately before timer-2 can begin execution.

The 4ms Clamping Rule (HTML Living Standard § 8.5.2)

When nesting setTimeout calls beyond 5 levels (nesting level > 5), browsers enforce a minimum delay of 4 milliseconds, even if delay = 0 was specified. This prevents recursive zero-delay timers from completely monopolizing CPU resources.

setInterval Drift vs Recursive setTimeout

setInterval(fn, 1000) schedules calls at 1000ms intervals regardless of how long fn() takes to execute. If fn() is an asynchronous API call taking 1200ms, calls will stack up or execute with zero gap, causing race conditions and performance degradation. The Senior Pattern: Use recursive setTimeout to guarantee that the next delay interval only begins after the previous operation completes:

function poll(interval) {
  return setTimeout(async () => {
    try {
      await fetchStatus();
    } finally {
      poll(interval); // interval strictly measured from completion
    }
  }, interval);
}

Asynchronous Concurrency Throttling Pattern

When processing hundreds of concurrent network requests, unleashing Promise.all can overload servers or trigger rate limits. Production systems implement concurrency pools (like p-limit):

async function asyncPool(limit, tasks) {
  const executing = new Set();
  const results = [];
  for (const task of tasks) {
    const p = Promise.resolve().then(() => task());
    results.push(p);
    executing.add(p);
    const clean = () => executing.delete(p);
    p.then(clean, clean);
    if (executing.size >= limit) {
      await Promise.race(executing);
    }
  }
  return Promise.all(results);
}