I/O multiplexing

Picture one waiter responsible for twenty tables. He cannot stand frozen at one table waiting for those guests to decide while the others wave for service. Instead he scans the whole room and goes only to the tables that need something right now. I/O multiplexing is that scan-the-room ability for a program: a way for one thread to watch many sockets at once and be told which ones are ready to read or write, so it never blocks on a single quiet connection.

Concretely, you set your sockets to non-blocking, hand the operating system a list of them, and call a multiplexing function: the classic select or poll, or the modern epoll on Linux and kqueue on BSD/macOS. That call blocks once, on the whole set, and returns the moment any socket in the set becomes ready — a listening socket has a new connection to accept, a client socket has bytes to recv, or a socket's send buffer has room. Your code then loops over just the ready sockets, does a quick non-blocking operation on each, and goes back to waiting. This single-thread loop is called an event loop, and the work it does in response to each ready socket is an event handler.

Why it matters: I/O multiplexing is how a single thread can serve tens of thousands of connections, the famous C10k problem, without spawning a thread or process per client. It powers high-performance servers (Nginx, Redis) and the runtimes of Node.js and asyncio. The honest trade-offs: the code is harder to write than straight-line blocking code, because logic gets split across callbacks or coroutines, and a slow blocking operation accidentally placed inside the loop (a synchronous disk read, a DNS lookup) stalls every connection at once. Multiplexing tells you a socket is ready; you still must do partial reads and writes correctly.