W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

RE: Future feedback

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Thu, 16 May 2013 04:42:41 +0000
To: Sean Hogan <shogun70@westnet.com.au>, Boris Zbarsky <bzbarsky@MIT.EDU>
CC: David Bruant <bruant.d@gmail.com>, Jonas Sicking <jonas@sicking.cc>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F7EF9A380@BY2PRD0510MB354.namprd05.prod.outlook.com>
From: Sean Hogan [mailto:shogun70@westnet.com.au]

> Say I have three tasks (micro-tasks, whatever) which are scheduled by the following:
> 
> 
> Future.accept()
> .then(function() {
>      task1();
>      task2();
> })
> .then(function() {
>      task3();
> });
> 
> All three tasks perform DOM manipulation, but don't lookup any dimensions or compute any styles.
> 
> Assuming a **best-case scenario** (including that the Futures spec is implemented):
> 
> 1. Is there a page-reflow between task1 and task2?
> 2. Is there a page-reflow between task2 and task3?
> 3. What is the timing interval between task2 and task3? Milliseconds is fine.
> 
> I know the answer depends on many things. I'm only interested in the **best-case scenario**.

For the record, regardless of how it's currently specified, no important invariants are broken if task1, task2, and task3 are all executed in sequence with no yielding of any sort between them. That is, no page reflows between any of the tasks, and zero seconds between task2 and task3.

This could be in practice accomplished (speaking in user-space, not browser-implementation-space) by, when a promise is fulfilled, waiting until the end of the current microtask, then performing all relevant state transitions (including those for promises resolved to the original promise) and executing all consequent onFulfilled handlers.

We are having discussions of this exact sort at https://github.com/promises-aplus/promises-spec/pull/104 FYI.
Received on Thursday, 16 May 2013 04:43:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC