select, poll, epoll and kqueue

Blocking read() on one socket parks the thread until *that* socket has data, so it cannot serve others; checking each non-blocking socket in a loop spins the CPU and still adds latency. What is needed is a single call that sleeps until any of a set is ready — I/O multiplexing — so the kernel, which already knows when each socket buffer changes, does the waiting (I/O Multiplexing: select, poll, epoll, kqueue, IOCP).

select() was the first: pass three bitmaps of descriptors, sleep, get back bitmaps of the ready ones. Two problems: the bitmap is fixed-size (FD_SETSIZE, 1,024 on most systems) and every call is O(n) — the kernel scans all n descriptors to check readiness, you rebuild the sets every time, and you scan the result. poll() removes the size limit with an array of struct pollfd but keeps the O(n) scan on both sides. At 10,000 mostly idle sockets, each call does 10,000 units of work to find the 5 that are ready.

epoll (Linux) and kqueue (BSD, macOS) fix the algorithm: you register interest once (epoll_ctl), the kernel keeps a ready list that it updates as events happen, and each epoll_wait returns only the ready descriptors — O(ready), not O(registered). That is the difference between a server that scales with active connections and one that scales with total connections, and it is what nginx, Node.js, Redis and every event loop are built on (The Event Loop). kqueue additionally covers file changes, signals, timers and process events in the same interface; Windows uses IOCP, a completion model rather than a readiness one.

Two semantic choices matter. Level-triggered (default) reports a descriptor as long as it is ready — simple, and you can read partially. Edge-triggered (EPOLLET) reports only on the *transition* to ready, so you must drain until EAGAIN or you will never hear about that socket again; it is more efficient and easier to get wrong. And none of these help with regular files, which are always "ready" on Linux and simply block on the actual read — that is why libuv and others use a thread pool for file I/O, and why io_uring exists (Async I/O: What `await readFile()` Actually Does).