Inside a long-running loop, does adding `await Promise.resolve()` on every iteration give the event loop a chance to run other queued work, the way `await new Promise(r => setTimeout(r, 0))` does?

## Two queues, two very different meanings A JavaScript runtime keeps at least two queues. The **task queue** holds whole units of work — a script evaluation, a timer callback, a dispatched event handler. The **microtask queue** holds continuations that must run before the runtime is allowed to move on — promise reactions and `queueMicrotask` callbacks. The processing rule is short: run one task to completion, then drain the microtask queue *entirely*, then and only then pick the next task. "Entirely" is the word that decides this question. If draining a microtask enqueues another microtask, that one is drained in the same pass. The checkpoint does not end until the queue is empty. ## Where `await` lands `await x` suspends the async function and schedules the remainder of it as a **microtask** once `x` settles. If `x` is already resolved — `Promise.resolve()`, or any non-promise value — the continuation is queued essentially immediately, so it runs at the very next checkpoint. ```js async function loop() { for (let i = 0; i < 1e6; i++) { doWork(i); await Promise.resolve(); // microtask hop, not a yield } console.log('done'); } setTimeout(() => console.log('timer'), 0); loop(); // 'done' prints before 'timer' ``` Every iteration hands control back to the runtime, but only as far as the microtask checkpoint — and because the loop immediately queues another microtask, the checkpoint keeps going. The task that started `loop()` cannot end until the entire million iterations are finished, so the timer scheduled before it still runs afterwards. The pending timer, and anything else in the task queue, is stuck behind a queue that never empties. That is microtask starvation, and it is exactly what a developer who reached for `await` as a "yield" was trying to avoid. ## Where the timer lands ```js const yieldToLoop = () => new Promise(resolve => setTimeout(resolve, 0)); async function loop() { for (let i = 0; i < 1e6; i++) { doWork(i); if (i % 1000 === 0) await yieldToLoop(); } } ``` Here the promise is *not* already resolved. It settles only when the timer callback runs, and the timer callback is a task. So the async function's current task ends, the microtask queue drains, and the runtime is genuinely free to pick the next task — which may well be a queued click handler or another timer scheduled earlier. The continuation resumes later, in a task of its own. Note the `if (i % 1000 === 0)`: crossing a task boundary is far more expensive than a microtask hop, because the host enforces a minimum delay on timers and each hop pays scheduling overhead. Yielding on *every* iteration would make the job orders of magnitude slower. Yield periodically, ideally on a time budget rather than an iteration count. ## The mental model to state in an interview - **Microtask** = "before anything else happens, finish this". It is an ordering tool: it guarantees your continuation runs before the next task, not that anyone else gets a turn. - **Task** = "I am done for now, take the thread". It is the yielding tool. So `await` is not a yield point in the scheduling sense. It is a *suspension* point in the language sense: it lets other code that is already running interleave with your continuation within the same task, which is how concurrency between multiple pending async operations works, but it never hands the thread back to the loop's task queue. ## The one case where `await` on a resolved value does something useful It is genuinely useful for ordering: deferring a read until every already-queued promise reaction has settled, or breaking a synchronous call chain so the caller's stack is gone before your code continues. That is a legitimate use — just not the same thing as releasing the thread. ## The diagnostic signature When someone has made this mistake, the symptom is distinctive: the UI is still frozen or the server still fails to answer other requests, even though the code is now full of `await`s and "looks async". Timers fire late in a burst after the loop finishes, in the order they were queued. Nothing appears to be blocking in the sense of a `while (true)` — the stack keeps unwinding and re-entering — yet no other task ever gets scheduled. The fix is always the same: make the awaited thing settle from a task, not from an already-resolved promise, and do it periodically rather than every iteration.