How an event loop works

The loop is a program shape: register interest in a set of descriptors, then call one blocking wait — epoll_wait on Linux, kqueue on macOS/BSD, IOCP on Windows — that returns when *any* of them is ready. For each ready descriptor run its callback to completion, then go back to waiting. One thread suffices because for a network service almost all time is spent waiting, and the kernel can wait on ten thousand sockets as cheaply as on one (I/O Multiplexing: select, poll, epoll, kqueue, IOCP, The Event Loop).

The contract is cooperative: a callback must return quickly, because nothing else runs until it does. Anything that keeps the loop thread busy freezes every connection: a JSON.parse of 50 MB, a synchronous file read, a regex with catastrophic backtracking, a tight loop, a synchronous DNS lookup. The symptom is distinctive — timers fire late, health checks time out, one core is at 100% and the rest are idle, and strace shows almost no syscalls because the thread is not waiting on anything (Async I/O: What `await readFile()` Actually Does).

It also cannot give parallelism. To use more cores you run more loops: Node.js cluster or worker_threads, one process per core behind a shared listening socket. And some operations have no non-blocking form — regular-file reads on Linux always "block" briefly, and getaddrinfo is synchronous — so Node.js (label: Node.js/libuv) runs those on a small thread pool (default size 4) and posts the completion back to the loop.

The trade-off against threads is scheduling: the kernel preempts a misbehaving thread; an event loop trusts every callback. That is why a slow callback hurts *all* clients at once rather than one, and why event-loop latency is the metric to alert on.