Reactor and proactor ownership

In a reactor design, a dispatcher waits for resource conditions and invokes the associated handler. That handler attempts I/O, interprets the result, and updates application state. A connection can therefore have readable input without containing a complete protocol frame. Separate the generic dispatcher from connection-specific parsing and request state. The dispatcher should not need to understand every message format, but its registration and lifetime rules must make it impossible to dispatch into an already-destroyed handler.

In a proactor design, an initiator requests an asynchronous operation and supplies enough state to associate a later result with its continuation. A completion dispatcher delivers the resulting status and progress. The operation might be carried out by an operating-system facility or by workers beneath an asynchronous facade. Application code must understand the actual contract rather than infer hardware behavior from the pattern name. Completion ordering and buffer lifetime remain explicit obligations even when initiating code looks sequential.

Several operations may reference the same connection while completing in a different order from submission. Store a stable operation identity and the expected transition with each request. Do not confuse a reused descriptor number with the original connection object. A generation number or another lifetime-safe handle can reject stale callbacks. The application must also decide whether two writes are allowed concurrently and how their ordering relates to its protocol; the dispatch pattern alone does not establish message order.

Draw ownership changes alongside control flow. Before submission, the application prepares a request and its buffer. While an operation is outstanding, permitted readers and writers follow the API contract. On a terminal result, the owner interprets progress and releases or transfers resources exactly once. If a task times out, some underlying work may still exist. A timeout continuation cannot free memory merely because the caller has stopped waiting. Error paths must respect the same terminal boundary as successful paths.

A readiness-based socket service may already have a good protocol state machine and modest copying costs. A completion-based storage pipeline may benefit from explicitly managing a bounded set of outstanding reads. Neither observation proves a universal winner. Compare supported operations, runtime portability, cancellation semantics, submission costs, memory pressure, and the complexity of shutdown. A hybrid often exists: one layer exposes futures while another layer uses readiness or a blocking worker pool. Review the boundary that your team actually owns.

The queue lab isolates only offered work and draining capacity. Press Reset, set arrival rate to 4 and service rate to 3, predict growth from the initial four-job backlog, then press Play. For a separate draining experiment, press Reset again, set arrival rate to 2 and service rate to 4, predict the slope, then press Play. Reset both rates for each new run rather than treating a slider edit as a mid-run capacity change. This can motivate bounding outstanding operations, but it cannot choose reactor versus proactor or count per-request notifications. For that choice, write two traces of the same request and mark the instruction that obtains its result, the component allowed to release its buffer, and the error path that removes its registration.