Call Stack and Run-to-Completion

## What the call stack is When a function is called, the engine must remember three things: the arguments it was called with, the local state it builds up while running, and where execution should resume once it returns. It packages that into a **frame** (in specification language, an execution context) and places the frame on a stack — a last-in, first-out structure. A call pushes a frame; a return pops it. The stack is a fixed-size memory region the engine manages for you; you never allocate or address it directly, you only observe its shape through debuggers, profilers and error stack traces. ## Push and pop, in strict order ```js function inner() { console.log('inner running'); } function outer() { inner(); console.log('outer resumes'); } outer(); ``` At the moment `console.log('inner running')` executes, three frames are live: `outer` at the bottom, `inner` above it, and `console.log` on top. `console.log` returns and pops; `inner` reaches its end and pops; control resumes inside `outer` exactly where it left off, because that resume point was stored in `outer`'s frame. Nothing else can be interleaved between those pops — the order is fully determined by the call structure. ## One stack per agent ECMAScript models a running program as an **agent**: one thread of execution, one job queue, one call stack. Within an agent, exactly one frame — the topmost — is executing at any instant. There are only two ways a different function starts running. Either the currently running function calls it, in which case its frame goes *above* the caller's and the caller is suspended in the ordinary sense (it is still on the stack, waiting for the callee to return); or the stack drains completely and the runtime picks up the next queued job, which begins on an empty stack. That second path is the important one. Every callback you ever write — a timer callback, a promise reaction, an event handler — starts at the bottom of an empty stack. It never appears halfway up somebody else's stack. This is why you can reason about a function's body as an uninterrupted unit. ## Then how does anything happen "in the background"? A single JavaScript stack does not imply the *host* is single-threaded. When you start a timer or a network request, the JavaScript call that starts it does almost nothing and returns immediately; its frame pops. The waiting, the socket work, the disk read — those are carried out by the host outside the JavaScript stack, quite possibly on other operating-system threads. When the work finishes, the host queues a job, and your callback runs later on a fresh stack. So the parallelism is real, but it is parallelism of *host work*, not of your JavaScript. Only one piece of your code ever holds the stack. ## What follows from it - **A function that never returns owns the runtime.** Its frame stays on the stack, the stack never empties, and no queued job can start. That is the whole mechanism behind a frozen page. - **You never observe half-updated state from a callback.** A callback cannot begin until the current stack is gone, so it can only ever see state as of a completed statement sequence. - **Frames also pop on `throw`.** An exception unwinds frames one by one until it finds one with a matching `catch`. If none exists, the job ends with an empty stack, the error is reported as uncaught, and the runtime moves on to the next job. - **Depth is finite.** Each live call consumes part of a fixed region, so nesting calls deeply enough exhausts it and the engine throws — the everyday sign that frames really are physical, not conceptual. ## Common misreadings The most frequent one is treating the stack as a queue: "my callbacks are sitting on the stack waiting." They are not — queued callbacks live in job or task queues, and the stack holds only calls currently in progress. The second is inferring extra threads from asynchronous syntax: `async` functions, promises and timers all run their JavaScript on the same single stack; nothing about them starts a second interpreter. The third is imagining the engine can pause your function to squeeze in an urgent callback. It cannot — there is no preemption point between your statements, which is exactly why JavaScript code needs no locks around ordinary object mutation.