domenic at domenicdenicola.com (2014-06-17T20:45:04.673Z)
On Jun 10, 2014, at 7:53 PM, Ian Hickson 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. Step 7 of EnqueueTask is intended for other purposes including managing host environment defined main switches. > (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. But you may feed Jobs into it one by one, rather than starting it off with a bunch of pending script execution tasks. 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. 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. Finally, not 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.
On Jun 10, 2014, at 7:53 PM, Ian Hickson wrote: > On Wed, 11 Jun 2014, Domenic Denicola wrote: >> From: Ian Hickson [mailto:ian at hixie.ch] >>> >>> Where in the ES spec are the ES jobs for promises queued up? >> >> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-triggerpromisereactions >> and >> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise.prototype.then; >> search for `EnqueueTask("PromiseTasks"`. > > 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. Step 7 of EnqueueTask is intended for other purposes including managing host environment defined main switches. > > (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. But you may feed Jobs into it one by one, rather than starting it off with a bunch of pending script execution tasks. 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. 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. Finally, not 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. Allen > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >