Coroutines as explicit state machines

Imagine a handler that reads a header, allocates a body buffer, waits for the body, and sends a response. At each genuine suspension, it needs a continuation: enough information to resume at the right step with the relevant values intact. Compilers and runtimes represent this in different ways, but the conceptual state machine is portable. A suspended task is not the same as a blocked operating-system thread. Many suspended tasks can share one loop thread while still consuming memory and external resources.

Distinguish running, suspended on a dependency, runnable after that dependency resolves, and terminal after success, failure, or completed cancellation handling. Resolution does not imply immediate execution. A continuation may wait behind other runnable work. Conversely, awaiting an already-ready result may not cause meaningful suspension. Avoid writing correctness arguments that depend on every await permitting another task to run. Mark actual state transitions in a trace rather than counting keywords in the source.

A task can check a shared condition, suspend, and resume after another task has changed that condition. Even without simultaneous execution on multiple CPUs, interleaving across suspension points can invalidate assumptions. If a connection changes generation or a request is superseded, the resumed continuation must verify that it still owns the right to update state. Use explicit ownership transfers, synchronization appropriate to the runtime, or single-owner message handling. Sequential-looking syntax is not a transaction spanning every suspension.

Local references also keep objects alive. A parser that retains a large receive buffer across a slow downstream await can consume substantial memory under concurrency, even if its CPU time is tiny. Release unnecessary references before the suspension when ownership permits, copy only the needed compact result when beneficial, or bound the number of such tasks. Do not free a buffer still used by an outstanding low-level operation. The continuation’s lifetime and the kernel operation’s lifetime may end at different moments.

Log stable task and request identities, the current logical stage, suspension cause, and terminal reason. A stack snapshot can show where a task is waiting, but interpreting it requires understanding the dependency and ownership relationship. Count tasks by stage instead of reporting only a total. Thousands awaiting a bounded pool may suggest different action from thousands blocked on one downstream connection. Resource limits should follow the stage that actually retains expensive buffers, not merely a global estimate of average task cost.

The queue lab offers a related capacity view, not a coroutine scheduler. Press Reset, set arrival rate to 4 and service rate to 3, predict accumulation from the initial four-job backlog, then press Play. To compare draining, press Reset again, explicitly set arrival rate to 2 and service rate to 3, predict the new run, then press Play. These independent runs do not carry the earlier backlog forward. The controls do not create, suspend, or resume individual coroutines and cannot measure frame sizes. Alongside the lab, draw the header-read, body-read, response-write states and annotate which objects survive each suspension. Ask which reference can be released before a slow response operation without violating the remaining operation’s buffer contract.