← Lessons

quiz vs the machine

Gold1360

Concurrency

The IO Multiplexing With Epoll

The kernel primitive that lets one thread watch thousands of sockets efficiently.

5 min read · core · beat Gold to climb

The IO Multiplexing With Epoll

An event loop needs a way to ask which of many connections are ready. The general term is IO multiplexing. Early interfaces called select and poll did this by scanning a list of every socket on each call, so cost grew linearly with the number of connections even when only a few were ready.

Epoll on Linux fixes that. You register interest in a set of sockets once. The kernel then maintains a ready list and a single wait call returns only the sockets that actually have events. Work scales with the number of ready connections, not the total.

  • Register once Add a socket to the epoll set and the kernel remembers it across calls.
  • Ready only The wait call returns just the active sockets, so ten thousand idle connections add no per call cost.
  • Edge or level Edge triggered fires once when state changes, level triggered fires while data remains, trading efficiency against simplicity.

Epoll, alongside kqueue on the BSD family and IOCP on Windows, is the engine that makes the C10k goal achievable. The event loop is the pattern, epoll is the kernel mechanism that makes it cheap.

Key idea

Epoll lets a thread register many sockets once and receive only the ready ones, so IO multiplexing scales with active connections instead of total connections.

Check yourself

Answer to earn rating on the learn ladder.

1. Why do select and poll scale poorly with many connections?

2. What makes epoll efficient at scale?

3. What is the difference between edge and level triggering?