Manipulation of the execution context stack

Allen Wirfs-Brock allen at
Mon Jul 21 13:49:43 PDT 2014

On Jul 21, 2014, at 1:29 PM, Ian Hickson wrote:

> On Mon, 21 Jul 2014, Allen Wirfs-Brock wrote:
>> 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 something?
>> A job (task in the version you're looking at)
> Is there a more up to date version I can look at? I couldn't quite work 
> out what the canonical file to look at was. I've been using this:

I just release a new PDF draft Friday at 

Hopefully, Jason will soon have the HTML version ready 

>> is always initialized (by NextJob) with an empty execution context 
>> stack.
> What step in NextJob does this? It seems that step 3 asserts it, but step 
> 1 doesn't seem to affect the stack, and step 2 refers to the "suspend" 
> prose, which seems mostly non-normative (I can't quite tell it's normative 
> status -- there's no step-by-step algorithms, which seems to be the way 
> the ES spec indications normativity, but there's no RFC2119-style prose 
> either, so I can't tell the descriptive statements in that section from 
> the prescriptive ones).

It's because NextJob is only supposed to be used within an Job initiation abstract operation that is passed to EnqueueJob.  So, since we start with an empty stack in 8.5 and each job each returns/unwinds to its starting context it flows like this

<empty stack>
create dummy root context
8.5 Initialization, does stuff
returns/unwinds to dummy root context
NextJob, deletes dummy root context, creates root context for first job
runs the initialization abstract operation for first job
returns/unwinds to first job root context
NextJob deletes first job root context, creates root context for second job

>> NextJob creates a root execution context and then transfers control (a 
>> goto, not a call)
> As phrased it's more like a tail-call, but the three are black-box 
> indistinguishable at the spec level, so that's somewhat academic.
>> [...] We are essentially faking up an initial current job state that 
>> NextJob can switch out of when scheduling the first real job.
> I guess what I'm saying is that it's not clear to me where the "switch 
> out" step happens. Do you have a pointer?

Did this help.  It essential to the process that jobs always unwind back to its root context.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list