domenic at domenicdenicola.com (2014-03-02T22:33:36.930Z)
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 Mon, Feb 24, 2014 at 9:45 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote: > 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 > https://github.com/Raynos/observ-hash/issues/2#issuecomment-35857671 and > then continue. > > Rev22 of the ES6 draft introduced the concepts of Tasks and TaskQueues: > http://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<http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-execution-contexts>and all Task Queues are empty. > > > 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. > Hi Allen, 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? > 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. > > Allen > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140224/5391ffa7/attachment-0001.html>