ES6 Tasks and TaskQueues
On Mon, Feb 24, 2014 at 9:45 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
Are Tasks the same as HTML Micro-tasks? Why are these called Tasks and not micro-tasks.
No, for the reason you state below. HTML's division of activities into Tasks, micro-Tasks, etc, assumes a particular priority relationship. EcmaScript is trying to be more general, to allow this and other priority relationships at the choice of hosting environment.
I intentionally didn't use the term "micro-task" to avoid confusion with HTML's use of that term. It's probably best to talk about the things called "Tasks" in the ES6 spec. as "ECMAScript Tasks". "Micro-task" (and "Task", I believe) have specific meaning and semantics within the context of HTML. I don't want to build the HTML semantics into the ES spec. because ES is also used in other platforms besides the browser/HTML environment. The expectation is that such platforms can use ECMAScript Tasks, TaskQueues, and platform specific scheduling rules to define the behavior of activities they push to the ES execution environment.
I agree that it's good to keep these levels separate by adopting distinct terminology. However, using the term "Task" to avoid confusion with html's use of <adjective>-Task does not seem like a good strategy. I am not surprised this causes more confusion than it avoids. I suggest that the priority-independent EcmaScript level concept be called "Turn", as it has exactly the semantics of a turn: It is a run-to-completion unit of execution that goes from an empty user-stack to an empty user-stack.
Are ECMAScript 6 Tasks insufficient support the HTML or other browser requirements?
Not as far as I know, but please let me know if you think something interferes with those requirements. ES Tasks are not intended to support all activity scheduling that might take place in a complex platform but only activities that involve the synchronous (to the activity) execution of ES code.
I was with you till this point. But did you mean to say "synchronous" rather than "asynchronous" above?
On Feb 24, 2014, at 10:11 AM, Mark S. Miller wrote:
I agree that it's good to keep these levels separate by adopting distinct terminology. However, using the term "Task" to avoid confusion with html's use of <adjective>-Task does not seem like a good strategy. I am not surprised this causes more confusion than it avoids. I suggest that the priority-independent EcmaScript level concept be called "Turn", as it has exactly the semantics of a turn: It is a run-to-completion unit of execution that goes from an empty user-stack to an empty user-stack.
Yes, that potential confusion has also been a concern. That's why in this message I starting calling them "EMAScript Tasks", similarly to how the ES spec. uses "EMCAScript function" to talk about functions implemented using ECMAScript code rather than the broader category of all functions. My second choice, if "ECMAScript Task" proves to be untenable would be "Activity". I'm not too fond of "turn", although I know it is a term that you favor. I don't think this use of the word "turn" is broadly enough known to provide many spec. readers an immediate intuitive feeling for the concept. Also, there might be some verb/noun confusion for non-native English speakers.
But, in the end I'll be fine with using whatever term TC39 favors.
I was with you till this point. But did you mean to say "synchronous" rather than "asynchronous" above?
I was afraid that might be confusing which is my I added the parenthetical qualifier. I was referring to the synchronous relative FIFO ordering within a single TaskQueue.
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:
-
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.
-
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.
-
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.
Perhaps we can flip this around:
-
What would an example implementation look like, wherein ES tasks are different from HTML micro-tasks?
-
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 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.
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: www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#processing-model-4 ?
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.
Is "chore" better than "turn"?
On Mar 3, 2014, at 4:32 PM, Mark S. Miller wrote:
Is "chore" better than "turn"?
Mark, to me "turn", as a noun, sounds like a "scheduling slot" rather than the thing that gets scheduled into the slot. For example: "in the next turn, we will run the handler for promise p". The thing that gets enqueue is "the task of running the handler for promise p" rather than the "turn in which p get handled".
Now its just a word that we are assigning our own meaning to, so we can use "turn" if we want. But is that equivalence of "turn" and "task" really what you're used to, and something whose meaning is intuitive enough?
Allen Wirfs-Brock wrote:
Now its just a word that we are assigning our own meaning to, so we can use "turn" if we want. But is that equivalence of "turn" and "task" really what you're used to, and something whose meaning is intuitive enough?
On naming, we can use Turn instead of Task if enough people get it. I like it (much better than longer "Activity" which is quite vague in comparison, and even better than even longer "ECMAScript Task"). So +1 for Mark's proposal from me.
More substantively, I'm concerned that you don't understand HTML microtasks but conjecture that they can be layered on top of ES tasks. I'm not necessarily faulting you alone here! The HTML specs I've read over the years at whatwg.org are maddeningly strung out and (I think) incomplete in defining tasks and microtasks. Perhaps they are better now.
Who will understand both HTML and ES6 draft and make sure your conjecture is true?
Le 24 févr. 2014 à 19:40, Allen Wirfs-Brock <allen at wirfs-brock.com> a écrit :
I don't think this use of the word "turn" is broadly enough known to provide many spec. readers an immediate intuitive feeling for the concept.
It seems to me that the word "turn" is widely used in that sense for turned-based games such as chess, so that it has a good chance to be understood. Or am I mistaken?
On Mon, Mar 3, 2014 at 4:57 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
Mark, to me "turn", as a noun, sounds like a "scheduling slot" rather than the thing that gets scheduled into the slot. For example: "in the next turn, we will run the handler for promise p". The thing that gets enqueue is "the task of running the handler for promise p" rather than the "turn in which p get handled".
Now its just a word that we are assigning our own meaning to, so we can use "turn" if we want. But is that equivalence of "turn" and "task" really what you're used to, and something whose meaning is intuitive enough?
In a time slicing or real-time system, in which future scheduling slots are (even approximately) pre-allocated to specific future times, drawing such a distinction makes sense. But in a run-to-completion event-loop system such as E and JavaScript, I have never found the need for this distinction, and I think it would cause more confusion than it would avoid. The future scheduling slot really has no existence apart from the activity which is scheduled to take place within this slot.
The erights.org website, several of my papers[1], and papers by others[2] make use of the "turn" terminology I'm suggesting. I have gotten many questions about many issues over the years about this material, but I have never encountered confusion caused by the choice of the term "turn", nor by the absence of a distinction between the scheduling slot and the activity that takes place in this slot. If the authors of some of these other papers have a contrary experience, please post. Thanks.
[1] research.google.com/pubs/pub40673.html, research.google.com/pubs/pub35127.html, erights.org/talks/promises/paper/tgc05.pdf, erights.org/talks/thesis/markm-thesis.pdf
[2] soft.vub.ac.be/Publications/2013/vub-soft-tr-13-05.pdf, www.hpl.hp.com/techreports/2010/HPL-2010-155.html, scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1230&context=etd_projects, www.usenix.org/conference/atc12/technical-sessions/presentation/yoo, soft.vub.ac.be/~tvcutsem/invokedynamic/presentations/T37_nobackground.pdf, code.google.com/p/ambienttalk/wiki/EssenceOfAmbientTalk
On Mar 3, 2014, at 10:04 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
Now its just a word that we are assigning our own meaning to, so we can use "turn" if we want. But is that equivalence of "turn" and "task" really what you're used to, and something whose meaning is intuitive enough?
On naming, we can use Turn instead of Task if enough people get it. I like it (much better than longer "Activity" which is quite vague in comparison, and even better than even longer "ECMAScript Task"). So +1 for Mark's proposal from me.
More substantively, I'm concerned that you don't understand HTML microtasks but conjecture that they can be layered on top of ES tasks. I'm not necessarily faulting you alone here! The HTML specs I've read over the years at whatwg.org are maddeningly strung out and (I think) incomplete in defining tasks and microtasks. Perhaps they are better now.
To totally don't understand all the subtleties of HTML tasks and microtasks. But I'm confident that they can be layer above the ES6 tasks because ES 6 really only provides a way to partially order the execution of EStasks and a hook that permits a host to schedule and initiate run to completion calls of EStasks. It the extreme a host could use a single element ES6 task queue and only queue an EStask when it is next to run.
On Tue, Mar 4, 2014 at 5:59 AM, Claude Pache <claude.pache at gmail.com> wrote:
It seems to me that the word "turn" is widely used in that sense for turned-based games such as chess, so that it has a good chance to be understood. Or am I mistaken?
Thanks Claude, this was indeed part of my rationale in choosing the term. Each player in playing a board game engages in activity that occurs over the course of play. But this activity is broken up into a series of turns. Each turn is atomic, and is the unit of interleaving among the activities. The overall activity of any one player can change course over time, in reaction to state changes caused by previous turns.
The other reason is more kinesthetic/visual. It plays well with the term "event loop", as in each turn is another twist of the event loop. This comes out especially well in some of Tom's diagrams at soft.vub.ac.be/~tvcutsem/invokedynamic/presentations/T37_nobackground.pdf
Mark,
As I've already said, I can live with "Turn". It's big advantage is that it completely avoids confusion with the HTML Task/Micro-task concepts.
On Tue, Mar 4, 2014 at 5:59 AM, Claude Pache <claude.pache at gmail.com> wrote:
Le 24 févr. 2014 à 19:40, Allen Wirfs-Brock <allen at wirfs-brock.com> a écrit :
I don't think this use of the word "turn" is broadly enough known to provide many spec. readers an immediate intuitive feeling for the concept.
It seems to me that the word "turn" is widely used in that sense for turned-based games such as chess, so that it has a good chance to be understood. Or am I mistaken?
I agree with Claude and others who feel that "turn" is confusing - in every outside use of "turn" as a noun, it refers to the time-slice in which you take actions, not the actions themselves. It is sometimes used slangily to refer to "the things you did during the timeslice", like "Argh, your turn destroyed my plan, now I've got to think more.", but in general using "turn" to refer to an action feels extremely weird to me.
At least for me, this intuition comes from my long experience as a gamer of various sorts - this usage applies equally to card games, board games, video games, etc.
I won't die if it ends up getting used, but I'd greatly prefer a different term.
The benefit of "turn" is that I've seen this terminology used almost exclusively for denoting an atomic turn of an event loop ("tick" is also often used). By contrast, terms such as "task" are used much more broadly (e.g. tasks scheduled on a thread pool). Just my 2c.
On Tue, Mar 4, 2014 at 10:47 AM, Mark S. Miller <erights at google.com> wrote:
Hi Tab, you are reading Claude's message in the opposite way that I am.
Oh shoot, I think I am.
Well then, I disagree with Claude, for the reasons I stated. ^_^
On Mar 4, 2014, at 11:03 AM, Tom Van Cutsem wrote:
The benefit of "turn" is that I've seen this terminology used almost exclusively for denoting an atomic turn of an event loop ("tick" is also often used). By contrast, terms such as "task" are used much more broadly (e.g. tasks scheduled on a thread pool). Just my 2c.
I think we can think of the entire scheduling mechanism described in the ES6 spec. as an "event loop" in the sense you use the term, but the terminology get complicated by the fact the we will ultimately have (HTML today, ES in the future) a user level Event abstraction and that some of the ("turns", "tasks", whatever ) scheduled via by the ES6 spec. mechanism will run "Event handlers" for the user level Event abstraction while other ('turns", "tasks", etc.) won't have anything to do with that abstraction.
So, we move the potential for confusion from between HTML and ES Tasks to confusion between ES Language level Events and ES engine level events.
On Tue, Mar 4, 2014 at 2:03 PM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
The benefit of "turn" is that I've seen this terminology used almost exclusively for denoting an atomic turn of an event loop ("tick" is also often used).
I was drafting a response that said exactly this, came back from lunch and Tom's post was here. Pardon the "dog piling", but +1.
Le 4 mars 2014 à 19:47, "Mark S. Miller" <erights at google.com> a écrit :
Hi Tab, you are reading Claude's message in the opposite way that I am.
Hi Claude, which did you mean?
I just meant that, since "turn" is a term widely used in context of turn-based games, it would be understood even by non-native speakers. Effectively, "turn" refers to the time-slice rather than to the actions taken during that time, as Tab says; but since I didn't considered what is exactly an ECMAScript task, I cannot say if that would be confusing.
Tom Van Cutsem wrote:
By contrast, terms such as "task" are used much more broadly (e.g. tasks scheduled on a thread pool).
Yes, and a Task (e.g., in Rust; akin to goroutine in Go or Process in Erlang) can be suspended voluntarily. The use of "task" goes way back (multi-tasking).
I think we want a different word, not only to avoid confusion with respect to HTML5, but because JS event loop "runs" or "turns" really are different from those other "tasks" from CS literature and OS/PL research.
I was going to respond via github to this issue comment, but I figured the answer probably was of interest to a broader audience. So go and read Raynos/observ-hash#2 and then continue.
Rev22 of the ES6 draft introduced the concepts of Tasks and TaskQueues: people.mozilla.org/~jorendorff/es6-draft.html#sec-tasks-and-task-queues. A Task is a non-interruptable, run to completion activity within the ECMAScript execution environment that typically includes the evaluation of ECMAScript code. A TaskQueue is a FIFO queue of Tasks that are waiting to run. Tasks were added to ES6 in support of Promises. They are also useful for describing the execution sequences of top level scripts and hopefully other features that may be added post ES6.
Rev22 defines two built-in tasks queues A queue for promise tasks and a queue for script evaluation tasks. Other task queues may be added in the future and an host platform may defined additional task queues and new kinds of tasks.
The ES6 spec. does not define a complete scheduling algorithm for tasks, instead it says:
The PendingTask records from a single Task Queue are always initiated in FIFO order. This specification does not define the order in which multiple Task Queues are serviced. An ECMAScript implementation may interweave the FIFO evaluation of the PendingTask records of a Task Queue with the evaluation of the PendingTask records of one or more other Task Queues. An implementation must define what occurs when there are no running execution context and all Task Queues are empty.
Are Tasks the same as HTML Micro-tasks? Why are these called Tasks and not micro-tasks.
I intentionally didn't use the term "micro-task" to avoid confusion with HTML's use of that term. It's probably best to talk about the things called "Tasks" in the ES6 spec. as "ECMAScript Tasks". "Micro-task" (and "Task", I believe) have specific meaning and semantics within the context of HTML. I don't want to build the HTML semantics into the ES spec. because ES is also used in other platforms besides the browser/HTML environment. The expectation is that such platforms can use ECMAScript Tasks, TaskQueues, and platform specific scheduling rules to define the behavior of activities they push to the ES execution environment.
Are ECMAScript 6 Tasks insufficient support the HTML or other browser requirements?
Not as far as I know, but please let me know if you think something interferes with those requirements. ES Tasks are not intended to support all activity scheduling that might take place in a complex platform but only activities that involve the synchronous (to the activity) execution of ES code. Task queues are used to enforce necessary relative serialization of certain activities. The set of available task queues, their sizes (could be 1), and their relative scheduling order are left completely up to the host platform. Also, there is nothing that says a platform can't have another higher level scheduling mechanism (I'm thinking about mutator events here) that is used to populate ES Task Queues. ES Tasks/TaskQueues are so basic it hard for me to see how they would limit a host platform. But, let me know if you see a problem.
Do ES Tasks have a ES API? Not currently. It would be easy enough to define an API for enqueing the invocation of an ES function as a ES Task. Also you can imagine APIs for defining TaskQueues and setting scheduling policies for TaskQueues. That is all post ES6 work and requires somebody to develop proposals and champion them. If HTML (or any other platform) is considering defining a capability like that (which isn't in other ways semantically couple to that platform) it would be nice to see it done as a ES feature proposal.