Event Loop and Concurrency

No. .then never calls back synchronously: it schedules a promise reaction job on the microtask queue. The callback runs after the currently executing script or task finishes, when the engine drains microtasks at its checkpoint.

It prints start, end, promise, timeout. All the top-level synchronous code runs first, then the promise callback runs as a microtask once the script finishes, and the setTimeout callback runs last as a separate task.

setInterval returns a timer handle — a number in browsers, a Timeout object in Node — whose only use is to pass to clearInterval. Without that call the timer fires forever, keeping its callback and everything the callback closes over alive.

setTimeout's delay is a minimum wait, not an exact schedule. When it elapses the callback is only queued as a task; it runs after the currently executing code finishes and after any work already queued ahead of it, so it commonly fires late.

setTimeout(fn, 0) schedules fn as a separate later task instead of running it now. Every remaining statement in the current script runs first, then all pending promise callbacks, and only then does fn execute — typically a few milliseconds later.

No. A JavaScript job runs until its call stack is empty, and only then does the runtime pick up the next callback, so nothing is preempted between statements. The guarantee covers one uninterrupted synchronous run — an await ends it and starts a new job.

At a microtask checkpoint the engine drains the entire microtask queue, running jobs until the queue is empty — including microtasks enqueued during the drain — before it starts the next task.

Awaiting an already-resolved promise does not yield to timers or input. The continuation after await is queued as a microtask, so the microtask queue never empties and the tab freezes just like a synchronous while(true) loop.

It prints script start, outer start, inner, script end, outer end, then. An async function runs synchronously up to its first await; everything after that await is a microtask, queued at the moment the await is reached.

It prints A, B, C, E, D. The function passed to the Promise constructor runs synchronously, and calling resolve does not stop it or run the then callback — that callback is queued as a microtask and runs after the script finishes.

setInterval measures its period from tick to tick, so a slow callback eats into the gap and can run back-to-back. A self-rescheduling setTimeout guarantees a full delay after each run finishes, at the cost of a period that grows by the callback's own duration.

The page freezes. The runtime drains the microtask queue until it is empty, and a microtask that re-enqueues itself never lets it empty, so the pending setTimeout callback, input handling and rendering never get a turn.

Every call in progress needs a stack frame, and the engine's stack region is fixed in size; recursion that nests deeply enough exhausts it and V8 reports that as a RangeError. A loop reuses one frame, so nothing accumulates.

Both run fn at the same microtask checkpoint, in enqueue order. queueMicrotask allocates no promise and returns nothing to chain, and a throw inside it surfaces as an uncaught error rather than becoming a promise rejection that can be silently swallowed.

Reschedule each step onto the task queue instead of the microtask queue — setTimeout(fn, 0), a MessageChannel message, or scheduler.yield() where available — and process a batch per turn so the runtime can run timers, input and rendering between batches.

It prints timer 1, microtask in timer 1, timer 2. A promise callback queued inside a timer callback runs as soon as that callback returns, before the runtime picks up the next timer callback.

The timer ignores whatever refresh() returns, so it starts a new one every second regardless: about three run concurrently, and the count grows if refresh slows down. Replace the interval with a self-rescheduling setTimeout armed only after each run settles.

Browsers apply the HTML standard's nesting clamp: once a timer chain runs more than five levels deep, a requested delay below 4 ms is raised to 4 ms. The engine is not lagging — the host is enforcing a floor.

Order is decided by expiry time, with ties broken by registration order: c runs first because it expires 50 ms earlier, then a, then b. Registration order only matters between timers that come due at the same moment.

No. Awaiting an already-resolved promise only queues a microtask, and microtasks are drained inside the current task before the runtime moves on, so the thread is never released. Only crossing a task boundary, such as awaiting a zero-delay timer, actually yields.

Keep a cursor into the array and process only as many items as fit in a small time budget, roughly 5 ms. When the budget is spent, call setTimeout with the continuation and a zero delay so the next batch runs as a fresh task, letting queued work run in between.

The handler holds the only call stack for four seconds, and no queued job can start until that stack is empty, so no other handler, timer or promise reaction runs and nothing repaints. Clicks made meanwhile are queued and their handlers fire in a burst afterwards.

MutationObserver delivers records as a microtask, not synchronously per mutation. Mutations accumulate in the observer's record queue during the synchronous run and are handed to the callback in one batch at the microtask checkpoint, so the callback sees the final state.

Record a performance profile of the frozen tab. Microtask starvation shows thousands of short, repeating callbacks with a shallow stack inside one task, whereas a blocking loop shows a single long frame. Pausing the debugger lands in the self-rescheduling step.

Guaranteed: current code runs to completion, all pending microtasks drain before the next task, and callbacks within one queue run first-in-first-out. Incidental: actual timer delays, ordering between unrelated task sources, and how many ticks a foreign promise implementation costs.

Counting ticks measures how many times the timer fired, not how much time passed. Each tick can only be late, never early, and the lateness accumulates. Compute remaining time from a timestamp captured at the start rather than from a tick count.

Hidden tabs get their timers throttled: typically no more than about once per second, and far less after several minutes in the background. Treat setTimeout as a wake-up hint and derive elapsed time from timestamps, never from how often a callback ran.

Flush at the microtask checkpoint when the batch must settle before anything outside your library can observe it; flush on a task when the runtime needs control back first. Microtasks extend the current turn; tasks let unrelated work interleave.

The delay is held in a 32-bit signed integer, so anything above 2147483647 ms (about 24.8 days) overflows. Browsers then treat it as zero and fire almost immediately; Node clamps it to 1 ms and prints a TimeoutOverflowWarning.