ES6 Tasks and TaskQueues
Mark S. Miller
erights at google.com
Mon Mar 3 16:32:30 PST 2014
Is "chore" better than "turn"?
On Mar 3, 2014 4:10 PM, "Allen Wirfs-Brock" <allen at wirfs-brock.com> wrote:
> On Mar 3, 2014, at 1:55 PM, Domenic Denicola wrote:
> I'd like some help understanding why we are not using the word
> "micro-tasks" here, and more generally why we are going our separate way
> and not trying to unify with HTML. Here is my understanding:
> I've specifically avoided the word "micro-task" because I'm not trying to
> specify all (really any) of the semantics of HTML micro-tasks. ES6 only
> needs to specify enough "multi-tasking" semantics to enable the
> specification of promises and the sequential evaluation of multiple
> scripts. In addition, I'm providing primitives that HTML or other host
> platforms might use to express the semantics of their own multi-tasking
> abstractions that trigger execution of ES code.
> - ES tasks are, essentially, purposefully under-specified versions of HTML
> micro-tasks. (That is, they have many unspecified behavior hooks, but a
> conformant HTML micro-task implementation will be a conformant ES task
> implementation that fills in those gaps.) They agree on all features,
> including the multiple queues, FIFO ordering requirements, empty-stack
> invocation, etc.
> I don't know whether this is true or not. I don't have a deep
> understanding of HTML micro-task and did not base what is in the ES6 spec.
> on them. Instead, I provided a small set of fundamental mechanisms that can
> be used to specify the sequencing of ES code execution. If what I ended up
> is an under specified version of HTML micro-tasks it sounds like I'm on the
> right track and that there are things that HTML needs to specify that are
> currently not needed by ES or possibly other host platforms.
> - All implementers whose engines include HTML micro-tasks will be using
> the same code for ES tasks and HTML micro-tasks. There may be some engines
> which do not include HTML micro-tasks---or something that meets that spec's
> requirements, but under a different name---however, I am not aware of them.
> How browsers factor their implementations isn't really my concern. But I
> an concerned about unnecessarily coupling the Es spec. with HTML. HTML is
> absolutely the most important host for ES, but it isn't the only one now or
> in the future.
> - Even if an implementer, which did not a priori implement HTML
> micro-tasks, were to create an implementation of ES tasks, that implementer
> would need to fill out the missing underspecified details, which would lead
> them to something probably exactly like HTML micro-tasks.
> Which details do you think are missing in this regard? There are a couple
> specific things that the spec. says a host or implementation must define
> (what happens when all queues are empty, the relative sequencing of script
> and promise task queues). If we have consensus on a single universal
> answer to these we could specify it. Otherwise, its best left to
> implementations and future editions of the ES spec.
> Perhaps we can flip this around:
> - What would an example implementation look like, wherein ES tasks are
> different from HTML micro-tasks?
> So is this the specification of "micro-tasks" I should be looking at:
> If so there seems to be all sorts of stuff in there that is very specific
> to browsers. It's basically
> Using the ES6 spec Task primitives, I could easily provide
> implemention-defined spec. pieces necessary for an ES implementation that
> just runs an externally provided script and services promises and it would
> be much simpler than the HTML processing model. It would basically be:
> Perform the single task in the LoadingTasks queue and then process the
> tasks in the PromiseTasks queue until it is empty. Then terminate.
> Probably need to add a a few works about what to do in the event that a
> task terminates via an uncaught exception.
> I think the more interesting exercise would be to tweak the webapps spec.
> so that it used the ES6 primitives for actual ES code execution.
> - Given that example, do we want to encourage such an implementation to
> exist? That seems to be what the two competing specs are doing.
> I'd say yes. I expect a command line ES engine to have a much simpler
> task processing model than a browser.
> I find it unnecessarily confusing that both ES and HTML are speccing out
> the same mechanism, with very many of the same features, and then
> pretending they are distinct. When in reality, i.e. in implementations,
> they are not going to be distinct at all---they are going to be exactly the
> same code, and nobody knows what to name the variables in that code because
> there are two competing specs with their own names for each concept.
> I certainly don't want to double specify anything. It seems to me, that
> the right division of labor is for ES to specific only the mechanism by
> which the execution of ES code can be initiated along with low level
> coordination mechanisms necessary to support actual control abstractions
> that exist in ES (ie Promises). Other specifications should add platform
> specific policies using those mechanisms and define control abstractions
> that aren't part of ES. Most of what is in HTML's processing model are
> platform policy issues of this sort.
> If/when ES adds new language/library abstractions such as events or a user
> level task abstraction, then the ES spec would provide the necessary
> semantics, just like it is doing for promises.
> BTW, I think I've found a conflict free word we could use instead of
> "ECMAScript task" its "chore". An ugly word but it seems to be available.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss