阅读中文版本

I/O Multiplexing with epoll and kqueue

I/O multiplexing waits on many file descriptors at once, notifying the program only when one is ready, which is how single-threaded servers handle thousands of sockets.

Definition

I/O multiplexing is a kernel facility that lets a program block on a set of file descriptors and be told which ones are ready for reading or writing, rather than checking each in turn.

It is the mechanism behind event-driven servers and runtimes on Linux and BSD systems. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

Epoll and kqueue register interest once and report only ready descriptors, avoiding the linear scan that select and poll perform on every call.

Edge-triggered mode reports readiness transitions rather than current state, so a handler must drain the socket until it would block or it will miss the next event.

Trade-offs and alternatives

Readiness guarantees only that a small read will not block, so code must still loop on partial reads and handle end of stream explicitly. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that multiplexing performs the reads and writes on the caller’s behalf. Another is that select, poll, and epoll have identical scaling behaviour. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to using level-triggered notifications without draining a socket and to building an event loop that does not handle partial reads. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Atomic Operations, Seqlocks, Lock Fairness and Starvation.