Imagine a receptionist watching several phones: instead of checking every line repeatedly, the receptionist waits and announces which ones need attention. select gives an operating-system event loop the same ability. It monitors registered sockets or file descriptors and blocks until one or more become ready for reading or writing. section 11.11 section 11.4
The wait applies to the notification, not to the eventual I/O operation. When sockets are already ready, select returns immediately; otherwise, it sleeps until an event arrives. The application can then process several sockets from one thread without repeatedly polling each socket itself. section 11.11 section 11.4
A typical event-driven arrangement follows this rhythm:
- Register sockets and the read or write events they should monitor. section 11.4
- Call select from the event loop and wait for ready events. section 11.4 section 11.5
- Invoke the callback associated with each returned event, then return to select when pending work is finished. section 11.5
A single-threaded pizza server
A pizza server can register its listening socket and client sockets, then use callbacks such as _on_accept(), _on_read(), and _on_write(). select identifies sockets ready for work; the event loop dispatches the matching callback, allowing multiple clients to make progress without multiple server threads. section 11.5
Use the event-multiplexing figure to visualize how monitored sockets, queued readiness events, and the event loop fit together. section 11.4
