Async and Event-Driven Models

An event loop is a single thread cycling forever: wait for ready events, take the next task from a queue, run its handler to completion, repeat. No handler is ever interrupted mid-way by another handler, so loop-owned state needs no locks — but a slow handler delays everything behind it.

A future is the read side of a result that is not ready yet: you await it or attach a continuation. A promise is the write side: the producer completes it once, with a value or an error. Splitting them stops consumers from completing results.

Mapping applies a synchronous function to the value. Chaining applies a function that returns another future and flattens it, so the result completes when the inner work finishes. Mapping with an async function yields a future of a future: the outer completes early, before the real work is done.

A future completes with either a value or an error, and an error short-circuits the downstream transforms until a handler that accepts errors is reached. A try/catch at the call site only sees synchronous failures, because the function returns a pending handle long before the failure exists.

Pure push has no rate control: a fast producer and slow consumer means unbounded queue growth and eventual memory exhaustion. Demand signalling lets the consumer declare capacity, and the producer may never emit more than the outstanding demand, so items in flight stay bounded without blocking any thread.

Each thread costs reserved stack memory, a kernel scheduling entity, and cache footprint. At 10k+ mostly idle connections you pay gigabytes of stacks and constant context switching for almost no work, so throughput falls while connections rise. Event loops decouple connection count from thread count.

Loop threads are shared by all connections, so a handler that blocks or computes long stops every queued event behind it — latency appears everywhere, not on the guilty endpoint. Find it by measuring event-loop lag, instrumenting handler durations, and profiling loop threads.

Yes. Single-threaded cooperative scheduling removes low-level data races — no two tasks touch memory at the same instant — but not logical races. Any suspension point is a place where arbitrary other tasks ran, so check-then-act sequences spanning an await can still be violated.

Everything queued behind it waits: all in-flight requests take up to 400 ms longer, timers fire late, heartbeats and health checks miss, and client timeouts fire in a burst that triggers retries. Detect it by measuring loop lag — schedule a known-interval timer and record its overshoot — plus per-handler duration histograms.

A future is a first-class value: you can store, return, and combine it, and it has one defined outcome — value or error. Callbacks invert control, nest as they compose, and each one invents its own error and completion convention. Futures cost allocation and clarity of stack traces.

A future carries exactly one outcome, once. A stream carries zero to many items over time plus a terminal completion or failure. Use a stream when results arrive incrementally, when there may be many or infinitely many, or when the producer's rate could outpace the consumer.

Non-blocking: the read returns instantly with whatever bytes already exist or a "not ready" answer, so the thread never sleeps but you must retry when told the handle is ready. Asynchronous: you hand the OS a buffer, it does the read, then signals completion.

Blocking means the thread stops running and cannot do anything else until the operation finishes. In a thread-per-request server that costs one request. In an event-driven runtime a handful of threads carry every request, so one blocked thread freezes many unrelated ones.

A stackful coroutine owns a real stack, so it can suspend from any depth, including inside a function that knows nothing about coroutines. A stackless one is compiled into a state machine holding only its own locals, so it can suspend only at explicit points in itself, but costs far less memory.

Rule: run one macrotask to completion, then drain the entire microtask queue — including microtasks that microtasks add — before the next macrotask. Microtasks exist so continuations of already-settled operations finish before new external events. Hazard: an endlessly self-enqueuing microtask starves all I/O and timers.

A timer promises a lower bound, not a deadline: the callback becomes eligible at the deadline and runs when the loop next gets to it. Delays come from a long-running handler, coarse OS wakeup granularity, and clamping. Loops keep deadlines in a min-heap or timer wheel and set their poll timeout from the nearest one.

Scan-based interfaces are O(n) per call in both copying and kernel work, where n is all watched handles — even if one is ready. Registration-based ones pay O(1) amortised per registration and return O(k) ready events, so cost tracks activity, not the size of the watch set.

It splits the body at each await into separate blocks and rewrites it as a state machine: an object holds a state number plus every local that outlives an await. Resuming calls a resume function that switches on the state and jumps to the right block. The continuation is the callback you never wrote.

Cancelling usually only completes the read side with a cancelled outcome so the consumer stops waiting. The producer keeps working unless it cooperates — polling a cancellation signal, being interrupted, or having its socket closed. Real cancellation needs a channel back to the producer plus resource cleanup.

Blocking pull gives free rate control but parks a thread per stream. Unrestrained push parks nothing but hands rate control to the producer, so surplus items pile up. Demand-driven push combines them: batched permits bound memory, push delivery keeps threads free. It wins with many concurrent, remote, rate-mismatched sources.

Level-triggered reports "data is available" on every wait until you drain it; edge-triggered reports only the transition from empty to non-empty. The stall bug: read once, leave bytes in the buffer, and no further edge ever arrives, so the connection hangs forever with data waiting.

Reactor: demultiplex readiness, then your loop does the transfer with your buffer, allocated on demand; errors surface on your call. Proactor: submit operation plus buffer, kernel transfers, completion event carries bytes and error. Proactor pins buffers per in-flight operation and batches better; reactor is more portable.

Size it from the queueing relation: concurrency needed = arrival rate x service time. Bound the queue so overload rejects fast instead of growing latency, and give each dependency its own pool. Offloading protects the event loop; it does not make the dependency faster or add capacity.

If the thread that must run the async operation's continuation is the very thread now sitting blocked waiting for its result, the work can never finish. It needs a bounded execution resource — one loop thread, a single-threaded context, or an exhausted pool — plus a blocking wait held by a member of it.

It comes from the stackless transform: only rewritten frames can pause, so the ability to pause must propagate to every caller. That duplicates APIs, blocks incremental adoption, and tempts unsafe sync-over-async bridging. Stackful coroutines, user-mode threads, and effect systems remove the split.

Loop-per-core shards connections and state across cores with no shared mutable data, so it scales near-linearly and avoids locks and cache-line contention — but it cannot rebalance a hot shard. One loop plus a worker pool balances load automatically but pays handoff latency, cache misses, and synchronisation on shared state.

Choose by problem shape. One result per request means futures or suspending code. Many items over time with a real rate mismatch and a bounded-memory requirement justifies streams. Weigh debuggability, the viral spread of the model through signatures, and whether the whole path is genuinely non-blocking.

Decide on workload shape and team cost, not fashion. Lightweight threads keep sequential code and stack traces and are the default. Choose an explicit loop when you need per-core sharding, tight buffer control, predictable tail latency, or the runtime cannot hide blocking calls you depend on.

Sync wrapping async ships a hidden blocking wait that can deadlock the caller's scheduler. Async wrapping sync ships a fake — it hides a thread the caller cannot size or bound. Best: implement each natively over a shared core, or pick one and let callers bridge explicitly at their boundary.