Event-loop fairness and bounded turns

On a single event-loop thread, a handler that computes for a long uninterrupted interval prevents other handlers on that thread from executing. Asynchronous syntax does not preempt ordinary CPU instructions. A wait that is already satisfied may also return immediately, so repeating an await-shaped operation does not necessarily yield useful scheduling opportunities. Inspect the runtime’s actual scheduling semantics and measure callback execution duration separately from time spent suspended. A quick happy-path handler can hide a pathological large-input branch.

Fairness policies define which ready item runs next and how much it may do. Round-robin ready queues, byte budgets, item budgets, and elapsed-time budgets each control a different quantity. A byte limit may fail to bound expensive parsing; a time limit needs clock checks and interruptible work units. Bound each turn and preserve continuation state. Offload truly blocking operations or long CPU work through an appropriate facility, while bounding that facility’s queue instead of simply moving overload out of sight.

An edge-triggered readiness handler cannot process a small amount, forget the resource, and assume another notification will arrive for remaining data. Instead, retain ready state and put the unfinished resource back on an application-level ready queue. Later turns continue from the saved offset. Only a suitable nonblocking stopping observation allows it to return to waiting for readiness. This separates notification collection from fair execution and prevents the false choice between starving peers and losing progress.

Timers and cancellation also require dispatch time. A deadline becoming due does not imply its handler executes at that exact instant. Record event-loop lag by comparing an intended timer deadline with actual callback start using a monotonic clock. A large gap suggests scheduling or CPU contention rather than an external network delay. Instrument queue age by work class so that a high-throughput connection cannot conceal starvation of health checks, interactive traffic, or shutdown callbacks. Priority itself requires a policy against indefinite exclusion.

Fairness guarantees are conditional. If admitted work exceeds sustained execution capacity, every request cannot receive a fixed latency merely because the dispatcher rotates its queue. Admission control, bounded queues, and overload responses must accompany scheduling. Separate fairness across connections from fairness across tenants: a tenant opening many connections can gain many turns unless the scheduler accounts at the tenant level. Measure waiting-time distributions and rejection rates together, since rejecting most work can make the remaining latency look excellent.

In the queue lab, press Reset, set arrival rate to 4 and service rate to 3, predict growth from the initial four jobs, then press Play. Changing scheduling order alone cannot reverse this positive fluid slope. For a separate draining run, press Reset again, explicitly set arrival rate to 2 and service rate to 3, predict the slope, then press Play. Each reset restarts the model rather than preserving the preceding backlog. This model does not represent round-robin selection, timer phases, priority, or individual starvation; it demonstrates the capacity condition that any fairness policy must face. On paper, compare an unlimited draining handler with one processing a fixed byte budget and explicitly recording that the connection remains ready for another turn.