Manipulation of the execution context stack
allen at wirfs-brock.com
Mon Jul 21 12:44:27 PDT 2014
On Jul 21, 2014, at 11:23 AM, Ian Hickson wrote:
> 8.5 Initialization step 4 says "Push newContext onto the execution context
> stack", and step 8 calls NextTask. 8.4.2 NextTask suspends the running
> execution context in step 2, then in step 3 asserts "The execution context
> stack is now empty". However, I can't find anything in the prose around
> suspension that actually pops the execution context stack. Am I missing
A job (task in the version you're looking at) Is always initialized (by NextJob) with an empty execution context stack. NextJob creates a root execution context and then transfers control (a goto, not a call) to the appropriate abstract operation that knows how to start the next job. When that new job eventually completes it will have returned to its initiating abstract operation with an empty execution context stack and its root exeuction context as the active context. Such job initiating abstract operations always end by chaining to another NextJob which suspends (and discards the previous job's root execution context) and starts the process over again for the next job.
The execution context stack for a job actually gets emptied by the normal evaluation of the ECMAScript code of the job. However deeply it calls into ES code it always either explicitly returns back up the stack or abnormal completions (typically exceptions) unwinds the stack back to the execution context of the abstract operation that initiated the job).
The reason that Initialization in 8.5 initially creates a Realm and an execution context is to put the ES environment into a configuration that matches what NextJob normally expects to find when we use it to transition to the next job. We are essentially faking up an initial current job state that NextJob can switch out of when scheduling the first real job.
More information about the es-discuss