Epoll and Kqueue: How Operating Systems Learned to Wait Efficiently

The piece explains how modern operating systems solved the scalability problem of waiting for I/O by shifting from repeated polling to kernel-driven notifications. Early approaches like select and poll required scanning every file descriptor on each wait, so cost grew with connection count. The core innovation of epoll (Linux) and kqueue (BSD/macOS) is registering interests once: the kernel maintains an interest set and a ready list, then notifies user space only when state changes. On Linux, code patterns use epoll_create1 to make an epoll instance, epoll_ctl to add or modify file descriptors, and epoll_wait to receive only active events; waiting becomes proportional to activity rather than capacity. epoll supports level-triggered mode (continual notifications while a condition holds) and edge-triggered mode (notify once on state change), with edge-triggered offering efficiency at the cost of more complex, non-blocking programming.

kqueue generalizes the same model beyond sockets to file changes, signals, timers, and process events, treating events as first-class objects. The fundamental shift is from pull (user repeatedly asks kernel) to push (kernel delivers events), making idle connections cheap and active ones drive work. That model underpins scalable servers: tens of thousands of connections, small thread pools, and event-driven runtimes. Languages like Go build their scheduler on top of epoll/kqueue by using non-blocking sockets, registering interests, and parking goroutines until the kernel wakes them, enabling massive concurrency without exposing async complexity.