Some event-loop runtimes keep two queues: a task queue (macrotasks) and a microtask/continuation queue drained after each task. What is the ordering rule, why does the second queue exist, and what hazard does it create?

## Two queues, two roles - **Macrotask queue (task queue)**: external work — an I/O readiness callback, a timer that expired, a task posted from another thread. Represents new input into the system. - **Microtask queue (continuation/job queue)**: the rest of a computation whose result is already available — a callback attached to an already-settled promise, a resumed continuation. ## The rule, precisely 1. Pop one macrotask, run it to completion. 2. Drain the microtask queue until it is empty. Microtasks enqueued *during* the drain go to the back of the same drain and run in this pass. 3. Do any per-iteration housekeeping (rendering, timer collection, readiness polling). 4. Repeat. Microtasks therefore always run *before* the next macrotask, and always in FIFO order among themselves. ## Why the distinction exists Consider a chain: parse a response, transform it, update a shared index, then notify. If each step is a continuation and the runtime treated all callbacks as macrotasks, a timer or a new socket event could be dispatched between steps and observe the index half-updated. By running continuations in a drain that completes before any new external event, the runtime gives the chain a coarser atomicity with respect to the outside world. A second reason is ordering determinism. Because settled-promise callbacks are always deferred to the microtask queue rather than sometimes invoked synchronously, the ordering is the same whether an operation completed instantly or after a delay. Without that rule you get "sometimes synchronous, sometimes not" callbacks, which is a classic source of nondeterministic bugs. ## The starvation hazard The drain runs until empty, and each microtask may enqueue more: ``` function spin(): scheduleMicrotask(spin) # re-arms itself scheduleMicrotask(spin) ``` The drain never terminates. The loop never reaches step 3: no I/O, no timers, no rendering, no health checks. Symptoms are nasty because the process is not deadlocked and not idle — one core is pegged, the loop's own metrics stop updating, and health probes time out. The realistic version is not an infinite loop but a hot chain: a recursive continuation that walks a large data set one item per continuation, or a producer that resolves faster than the consumer drains. The rule of thumb: **recursion or iteration that re-arms itself should use a macrotask, not a microtask**, so each turn gives the loop a chance to service I/O and timers. ## Ordering surprises Given, inside one macrotask: schedule a zero-delay timer, then attach a continuation to an already-resolved value, then do some synchronous logging. Order of output: the synchronous log first (still inside the current macrotask), then the continuation (microtask drain), then the timer callback (a subsequent macrotask). Candidates routinely predict timer-before-continuation because "zero delay means immediately". Zero delay only means *eligible* immediately; the continuation queue has strict precedence. ## Reasoning consequences Because the microtask drain runs to exhaustion before the next external event, the atomic unit with respect to external input is "macrotask plus its whole microtask drain". That is bigger than one handler — useful when you want a chain to appear indivisible, dangerous when you assume the loop stays responsive during it. For fairness you often want the opposite of atomicity: to give the loop a breath. Explicitly re-scheduling as a macrotask is the standard yield. Some runtimes also bound how many macrotasks are drained per iteration, or drain queues by phase, precisely to keep I/O from being starved by a hot task queue. ## What to say in an interview State the rule, name the purpose (continuations of settled work must finish before new external events, and callback timing must not depend on whether the result arrived instantly), then name the failure: unbounded drains starve I/O and timers, so self-re-arming work belongs on the macrotask queue.