What does selectors.DefaultSelector let one thread do that a blocking socket.recv() cannot?

### The problem A socket in blocking mode owns the thread that calls it. `sock.recv(4096)` returns when bytes arrive, and until then the thread is parked in the kernel doing nothing. That is a perfectly good design for one connection, and it is why the simplest servers are written thread-per-connection: accept, hand the socket to a thread, let that thread block. The cost shows up at scale - every idle connection holds a thread, each with its own stack and its own scheduling weight, and the machine spends its time context-switching between threads that are almost all waiting. Readiness multiplexing inverts the arrangement. Instead of *one waiter per connection*, you have *one waiter for all connections*: the thread asks the kernel a single question - "of these N descriptors, which can I touch without blocking?" - and the kernel answers with the small subset that is actionable. ### The API ```python import selectors, socket sel = selectors.DefaultSelector() sel.register(conn, selectors.EVENT_READ, data=bytearray()) for key, mask in sel.select(timeout=1.0): if mask & selectors.EVENT_READ: chunk = key.fileobj.recv(4096) ``` Three pieces matter. **`register(fileobj, events, data=None)`** records an interest. `fileobj` is any object with a `fileno()` - a socket, a pipe end, anything the platform can poll. `events` is a bitmask of `selectors.EVENT_READ` and `selectors.EVENT_WRITE`. `data` is yours: the module never inspects it, and it is the intended place to hang per-connection state such as an input buffer, an output queue, or a callback. Without it you end up maintaining a side dictionary keyed by file descriptor, which is exactly the bookkeeping the `data` slot removes. **`select(timeout)`** is the blocking point of the whole program. It returns a list of `(SelectorKey, events)` tuples. The `selectors.SelectorKey` is a named tuple of `fileobj`, `fd`, `events` (what you registered) and `data` (what you attached); the second element of the tuple is the mask of what is ready *now*, which is a subset of what you registered. A `timeout` of `None` blocks indefinitely, `0` polls and returns immediately, and a number is an upper bound - the timeout is how a real loop makes room for timers and periodic work. **`modify()` and `unregister()`** change or drop an interest, and `get_map()` exposes the live registration table, which is a genuinely useful health metric. ### What DefaultSelector actually is `selectors.DefaultSelector` is not a class of its own; it is a name bound at import time to the most efficient implementation available on the platform. On Linux that is the epoll-backed selector, on the BSDs and macOS the kqueue-backed one, otherwise a poll-based one, and finally `selectors.SelectSelector`, which wraps `select.select`. The distinction is not cosmetic: the select- and poll-based backends hand the kernel the entire descriptor set on every call, so their cost grows with the number of *watched* descriptors, while epoll and kqueue keep the interest set in the kernel and report only the *ready* ones. The select backend additionally cannot exceed a compile-time descriptor-set size, commonly 1024 on Unix builds. Writing against `DefaultSelector` gets you the good backend on the platforms that have one without any conditional code. ### Readiness is a hint, not a delivery Two misreadings cause most bugs here. First, the selector never moves bytes. It tells you a call will not block; you still call `recv()` or `send()` yourself. A readable listening socket means `accept()` will not block; a readable connected socket means `recv()` will return promptly - possibly with `b""`, which is the peer's clean close and your cue to `unregister()` and `close()`. Second, readable does not mean *complete*. TCP is a byte stream with no message boundaries, so one readable event may deliver half a request, or two requests glued together. The loop's real job is to accumulate into the per-connection buffer you hung off `data` and parse out whole messages as they become available. For the same reason, registered sockets must be set non-blocking: readiness can be stale by the time you act on it, and a blocking `recv()` on a socket that turned out to have nothing would freeze every other connection in the process. ### What it costs The price of the model is control flow. Blocking code reads top to bottom; a readiness loop is a dispatcher over explicit per-connection state machines, because no connection may ever be allowed to stall the single thread. That is precisely the ergonomic problem `async`/`await` exists to solve - and the event loop underneath it is doing exactly what the loop above does. It is also worth being clear about the boundary: a readiness loop scales *waiting*, not computing. One thread still means one core, so CPU-heavy work inside the loop delays every connection registered with it.