Imagine asking a pizza shop to call when an operator is free. You can do something else instead of waiting on the phone. In an event-driven program, a callback plays the same role: it is a function supplied in advance to run when a specified event occurs. section 11.2
Callbacks need something to notice events and call the right function. An event loop waits for events, matches each one to a registered callback, runs it, then returns to waiting. In a simple Python example, one event can even register another event for the loop to handle later. section 11.3
A server that answers when sockets are ready
A single-threaded pizza server assigns separate callbacks to accepting a connection, reading a message, and writing a reply: _on_accept(), _on_read(), and _on_write(). It registers sockets and their expected events with an event loop. The loop waits in select until a socket is ready, calls its matching callback, and regains control when that callback finishes. This combination of nonblocking I/O, I/O multiplexing, and event-specific handlers is the reactor pattern. section 11.5 section 11.6
The trade-off is control flow. Work that once read as a sequence may be scattered across callbacks; nested chains can become hard to follow or debug. A callback that blocks also stops a single-threaded event loop from serving other events. Callbacks can provide results from asynchronous work, but they are one option, not the only one. section 11.2 section 12.1 section 11.7
