In JavaScript, once a function starts running, can a pending timer callback or promise reaction interrupt it partway through? Explain what run-to-completion guarantees and where that guarantee stops.

## What run-to-completion actually says A JavaScript runtime processes work in units usually called *jobs* or *tasks*: the initial evaluation of a script, a timer callback, an event handler, a promise reaction. The rule is that once one of these starts, it runs until the call stack is empty again. The runtime never suspends it partway to run something else and resume it later. Only when the stack drains does the loop pick up the next unit of work. So the answer to "can a pending callback interrupt my function?" is a flat no. A callback whose time has come simply waits. Its turn arrives when — and only when — the currently running job finishes and the stack is empty. ## Why that is a big deal In a preemptively scheduled language, a thread can be paused between any two machine instructions, so another thread may observe an object mid-update: half the fields written, an array resized but not filled, an invariant temporarily false. That is why such languages need locks, atomics and memory models. JavaScript hands you the strong property for free. Consider: ```js let n = 0; setTimeout(() => console.log('timer sees', n), 0); for (let i = 0; i < 1e6; i++) n++; console.log('sync done', n); ``` The output is `sync done 1000000` and then `timer sees 1000000`. There is no interleaving in which the timer prints `473812`. The timer callback is a separate job; it cannot begin until the loop's job has fully finished. The same holds for any multi-step update: if you write three fields of an object in a row, no other JavaScript in that agent can ever observe the object with only two of them written. This is the reason you never see mutexes or compare-and-swap in ordinary JavaScript code. They would have nothing to protect against. ## Where the guarantee stops: the job boundary The unit of protection is the job, not the function and not the module. Two things end a job in the middle of what looks like one piece of logic. The first is `await` (and, equivalently, a `.then` callback). When an async function reaches an `await`, it *returns* — its frame pops, the stack drains, the job ends. The code after the await is scheduled as a separate job and runs later, on a fresh stack. Everything queued in between gets to run first. So this is not atomic: ```js async function transfer(account) { const balance = account.balance; // job 1 reads await audit(account); // job 1 ends here account.balance = balance - 10; // job 2 writes a value read long ago } ``` If anything else touched `account.balance` while `audit` was pending, this write clobbers it. Nothing preempted `transfer`; the function was simply split into two jobs, and other jobs ran in the gap. The practical discipline is to re-read shared state *after* awaiting rather than caching it across the boundary, and to treat every `await` as a visible seam in your logic. The second is synchronous re-entrancy. Run-to-completion says nothing can be forced in; it does not say you cannot call out. If your code invokes a callback, a getter, a `toString`, or a listener that calls back into your own module, all of that runs on the same stack within the same job — and it can observe your object exactly as it is right now, halfway through your update. Libraries hit this constantly: finish mutating and restore your invariants first, notify afterwards, and be deliberate about what a handler is allowed to do while you are still inside your own critical section. ## The other edge of the same knife The guarantee is symmetrical. Because nothing can preempt a running job, nothing can rescue the runtime from a job that takes a long time either. A loop that runs for four seconds simply holds the stack for four seconds, and every queued callback waits. Run-to-completion is why JavaScript is easy to reason about *and* why a single slow function stalls everything. ## Common misreadings "`setTimeout(fn, 0)` runs `fn` immediately" — it cannot; zero only means "as soon as the queue reaches you", which is after the current job. "`await` pauses the thread" — it does the opposite: it releases the thread by ending the job. "Run-to-completion means an async function runs uninterrupted" — only each of its segments does. "JavaScript needs locks like other languages" — for ordinary shared objects within one agent, it does not.