On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
> > 
> > EnqueueTask() step 7 is where the HTML spec would hook in and treat 
> > different jobs as ending up in different task queues. Presumably, if 
> > we want all promise resolutions to be treated as microtasks, then that 
> > step would be overridden to queue a microtask when queueName = 
> > 'PromiseTasks', and queue a regular task otherwise (or whatever the 
> > other queues need), where that task/microtask would trigger the 
> > NextTask magic to run the actual job.
> 
> 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.


> > (As far as I can tell, in an HTML implementation the only queue name 
> > that is used is "PromiseTasks" currently, so maybe EnqueueTask() step 
> > 7 would just always queue a microtask. The only other queue name used 
> > in the ES spec currently is "ScriptTasks", but that one is never 
> > called in a browser environment, according to the discussion in the 
> > other fork of this thread, where I was talking about this with Allen.)
> 
> No, I think you would still use the "ScriptJobs" queue. It's the only 
> defined way to actually request ES execution of a Script.

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.

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.

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.


> 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?


> 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!)


> 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

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.


> No, I think you would still use the "ScriptJobs" queue. It's the only 
> defined way to actually request ES execution of a Script.

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.

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.

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.


> 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?


> 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!)


> 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.