Event Loops — Algorithmics

A thread waiting on a database call is doing nothing while it waits. Ten thousand concurrent requests, mostly waiting, means ten thousand mostly idle threads and ten gigabytes of stacks.

An event loop says: do not wait. Register what to do when the answer arrives, and go do something else.

The loop

while (running) {
  runUntilStackIsEmpty();      // execute current work to completion
  drainMicrotasks();           // all of them
  runOneMacrotask();           // then exactly one
  renderIfNeeded();            // browsers only
}

One thread, one queue of pending callbacks, one rule about which to run next. That rule is the part people get wrong.

What order does this print?

console.log('1');
setTimeout(() => console.log('2'));
Promise.resolve().then(() => console.log('3'));
console.log('4');

The answer is 1 4 3 2. Step through why:

Tick 1 / 7

console.log("1")
setTimeout(() => console.log("2"))
Promise.resolve().then(() => console.log("3"))
console.log("4")

call stack main

microtasks

macrotasks

output 1

Synchronous. Runs immediately.

A microtask that queues a microtask never yields

function loop() { Promise.resolve().then(loop); }
loop();      // freezes the page — permanently

The drain step runs microtasks until the queue is empty, and this queue never empties. No macrotask runs, no rendering happens, no input is processed. There is no error and no way out.

The setTimeout version of the same loop is fine, because a macrotask yields after each one.

The one rule

Never block the loop. There is one thread; anything slow stops everything.

// A 200ms sort is 200ms of frozen UI, and 200ms of no requests served.
const sorted = hugeArray.sort(compare);

Nothing warns you. The page simply stops responding, and in Node the server stops accepting connections.

The fixes, in order of preference:

Move it off-thread — a Web Worker in the browser, worker_threads in Node. This is the right answer for genuine computation.
Chunk it — process 1,000 items, await a macrotask, continue. Keeps the loop responsive at the cost of total throughput.
Do it elsewhere — a queue, another service, the database.

And beware the synchronous API: readFileSync, execSync, and crypto.pbkdf2Sync all block the loop completely. In Node these exist for startup scripts, not for request handling.

What you get for free

Because only one callback runs at a time, there are no data races. No mutexes, no atomics, no memory model. Any sequence of statements without an await is effectively atomic.

That is a real simplification, and it is why JavaScript has no synchronized keyword.

…but there are still races across an await

async function transfer(from: Account, to: Account, amount: number) {
  const balance = await from.getBalance();     // ← yields here
  if (balance < amount) return;
  await from.setBalance(balance - amount);     // ← and here
}

Between the read and the write, the loop runs other callbacks — possibly a second transfer on the same account. Both read the same balance, both approve, and the account goes negative.

Same lost-update shape as the threaded version, on one thread. Single-threaded means no torn reads; it does not mean no interleaving. Every await is a place another task can run.

Node’s loop has phases

Node’s macrotask side is not one queue but several, visited in order: timers, pending callbacks, poll (I/O), check (setImmediate), close callbacks. Plus process.nextTick, which runs before promise microtasks.

The practical consequences:

setImmediate fires after I/O in the current turn; setTimeout(fn, 0) fires in the next timers phase. Their relative order at the top level is genuinely nondeterministic.
process.nextTick jumps ahead of promises, and a nextTick loop starves the loop just as thoroughly as a microtask loop.

Reach for either only when you know which phase you need.