On Jun 10, 2014, at 9:35 PM, Ian Hickson wrote:

> On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
>> 
>> No, that's not the intent of the ES design.  The EnqueueTask abstract 
>> operations takes the name of a specific Job queue as an argument and 
>> always places the newly created PendingJob record into the named queue.  
>> It's important because the enqueuing order for a specific queue 
>> determine the relative ordering of the Jobs in that queue.  The whole 
>> reason we have a separate queue for promise Jobs is because we need to 
>> preserve that execution ordering.
> 
> Microtasks also preserve execution ordering.
> 
> My point is just that we need to maintain more than just promise callback 
> ordering -- we need to maintain the relative order of promise callbacks 
> and all the other things that trigger microtasks.

In the ES spec. I can only deal with things that are known to ES.  I need to be able to specify relative ordering of promise Jobs.  And I (implicitly) say that the ordering of promise jobs relative to script evaluation jobs is unspecified. 

I need to be able to expressed at least those concepts, without referring to specific host concepts, such as microtasks.

>> 
> 
> As far as I can tell, "ScriptTasks" (or "ScriptJobs") isn't actually used 
> anywhere in the spec except in 8.5 Initialization to queue a job. In 
> particular, nothing in NextTask is sensitive to the precise names of the 
> queues, it just grabs tasks from any job queue.

Yes, "ScriptJobs" essentially provides the default mechanism for a host to feed script execution requests to the ES engine.  But, a host really doesn't have to use it.  A ScriptEvaluationJob can be placed in any queue and dispatched by NextJob.

> 
> In practice, since we have to coordinate all the other tasks going on, and 
> since script execution for legacy scripts is not queued up in a job queue 
> but is instead done synchronously from HTML tasks, it seems like the 
> simplest way to actually manage this from the HTML side is to just spoon 
> feed the ES algorithms a single job at a time, so than NextTask only ever 
> has one job to chose from.

But you would still need to respect ordering relationships ES imposes, such as those for promise Jobs. You could in your NextJob extensions remove all entries from the "PromiseJobs" queue and (while preserving relative ordering) move them into your own scheduler.  Then feed them back to ES individually when you've decided that it's time to dispatch them.

> 
> This also seems like it would be easiest to implement from browsers, since 
> it means they'd only need one task management system (the HTML event 
> loop), and their requirements with respect to NextTask would boil down to 
> just "run this task", with no need to manage any queues at all.

That seems fine, as long as you preserve the ES specified Job orderings. 

> 
> 
>> The way I think about it is that HTML schedule queue needs to feed down 
>> to ES Job queues because it is the ES Jobs that define the actual 
>> execution semantics of ES code.
> 
> Well, we need to feed down to the specific algorithms that set up the 
> execution contxts and realms and so on, sure. But that's separate from the 
> job queues per se, no?

Right, that's essentially what the initial and final non-scheduleing related steps of NextJob takes care of.

> 
> 
>> HTML could schedule a microtask into the "PromiseJobs" queue if the 
>> microtask needs to be executed after all pending promise Jobs.  Or you 
>> could define you own ES "MicrotaskJobs" queue and define the ES 
>> scheduling relationship between it and the ES "ScriptJobs" and 
>> "PromiseJobs" queues.
> 
> We already have an event loop mechanism, I don't think it makes sense to 
> just recast the whole HTML mechanism into a JS mechanism. (JavaScript is 
> optional in browsers, after all -- we wouldn't want a browser to simply 
> not start up if the user disabled JS!)

We have Object.observe coming for ES and there is significant interest in having event-loop constructs as part of the core ES host independent environment.   Just like for promises, the ES spec. will have to define their semantics and any scheduling requirements for any associated Jobs in a manner that is independent of HTML or any other host environment.

Ideally, we probably should be designing this stuff in the context of several different host environments. You're the HTML integration point, and I try to keep a command-line JS host in mind.  Ideally somebody from a a more complex host such as Node should also be playing along. 

> 
> 
>> Finally, note that anything that is internally defined to use promises 
>> (for example, module loading phases) will end up getting schedule 
>> through the "PromiseJobs" queue as part of the promise resolution 
>> processing.
> 
> Yeah. I'm still wrapping my head around exactly how to integrate the 
> module loading stuff with all the other loading and dependency management 
> that HTML does.

Personally, I'd try to keep it all as local as possible.  There are many kinds of resources with their own unique dependency semantics and many levels of abstraction where dependencies can occur.  I don't know if it is possible to create a single universal dependency management model.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140611/d6c9a45f/attachment.html>

On Jun 10, 2014, at 9:35 PM, Ian Hickson wrote:

> Microtasks also preserve execution ordering.
> 
> My point is just that we need to maintain more than just promise callback 
> ordering -- we need to maintain the relative order of promise callbacks 
> and all the other things that trigger microtasks.

In the ES spec. I can only deal with things that are known to ES.  I need to be able to specify relative ordering of promise Jobs.  And I (implicitly) say that the ordering of promise jobs relative to script evaluation jobs is unspecified. 

I need to be able to expressed at least those concepts, without referring to specific host concepts, such as microtasks.

> As far as I can tell, "ScriptTasks" (or "ScriptJobs") isn't actually used 
> anywhere in the spec except in 8.5 Initialization to queue a job. In 
> particular, nothing in NextTask is sensitive to the precise names of the 
> queues, it just grabs tasks from any job queue.

Yes, "ScriptJobs" essentially provides the default mechanism for a host to feed script execution requests to the ES engine.  But, a host really doesn't have to use it.  A ScriptEvaluationJob can be placed in any queue and dispatched by NextJob.

> In practice, since we have to coordinate all the other tasks going on, and 
> since script execution for legacy scripts is not queued up in a job queue 
> but is instead done synchronously from HTML tasks, it seems like the 
> simplest way to actually manage this from the HTML side is to just spoon 
> feed the ES algorithms a single job at a time, so than NextTask only ever 
> has one job to chose from.

But you would still need to respect ordering relationships ES imposes, such as those for promise Jobs. You could in your NextJob extensions remove all entries from the "PromiseJobs" queue and (while preserving relative ordering) move them into your own scheduler.  Then feed them back to ES individually when you've decided that it's time to dispatch them.

> This also seems like it would be easiest to implement from browsers, since 
> it means they'd only need one task management system (the HTML event 
> loop), and their requirements with respect to NextTask would boil down to 
> just "run this task", with no need to manage any queues at all.

That seems fine, as long as you preserve the ES specified Job orderings. 

> Well, we need to feed down to the specific algorithms that set up the 
> execution contxts and realms and so on, sure. But that's separate from the 
> job queues per se, no?

Right, that's essentially what the initial and final non-scheduleing related steps of NextJob takes care of.

> We already have an event loop mechanism, I don't think it makes sense to 
> just recast the whole HTML mechanism into a JS mechanism. (JavaScript is 
> optional in browsers, after all -- we wouldn't want a browser to simply 
> not start up if the user disabled JS!)

We have Object.observe coming for ES and there is significant interest in having event-loop constructs as part of the core ES host independent environment.   Just like for promises, the ES spec. will have to define their semantics and any scheduling requirements for any associated Jobs in a manner that is independent of HTML or any other host environment.

Ideally, we probably should be designing this stuff in the context of several different host environments. You're the HTML integration point, and I try to keep a command-line JS host in mind.  Ideally somebody from a a more complex host such as Node should also be playing along. 

> Yeah. I'm still wrapping my head around exactly how to integrate the 
> module loading stuff with all the other loading and dependency management 
> that HTML does.

Personally, I'd try to keep it all as local as possible.  There are many kinds of resources with their own unique dependency semantics and many levels of abstraction where dependencies can occur.  I don't know if it is possible to create a single universal dependency management model.