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

Re: Future feedback

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 16 May 2013 00:43:57 -0400
Message-ID: <5194640D.80808@mit.edu>
To: Sean Hogan <shogun70@westnet.com.au>
CC: David Bruant <bruant.d@gmail.com>, Jonas Sicking <jonas@sicking.cc>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 5/16/13 12:32 AM, Sean Hogan wrote:
> Future.accept()
> .then(function() {
>      task1();
>      task2();
> })
> .then(function() {
>      task3();
> });
> Assuming a **best-case scenario**

Define "best-case"?  What are the criteria?

As far as how it behaves in practice, I believe some current UAs could 
do a reflow between task1 and task2 there, and in fact might do it while 
task1 is running.  Most current UAs would definitely not do anything 
between task1 and task2, since those run sync right after another.

The question is what happens with then(), right?  It seems to me that 
either it has to yield to the general event loop (and allow reflow to 
happen sometimes) or it needs to be subject to things like slow-script 
dialogs.  Given that as I understand the point of this setup is to 
encapsulate fundamentally async computations, yielding to the event loop 
makes the most sense to me...

Note that just because reflow _can_ happen between task2 and task3 
doesn't mean it _will_.  UAs do try to not reflow too often and all.

> 3. What is the timing interval between task2 and task3? Milliseconds is
> fine.

Seems like "milliseconds unless something else hogs the event loop" 
should be trivial to achieve: you can get that right now with 
setTimeout, which is not throttled for a bit, then throttles to 4ms.

Received on Thursday, 16 May 2013 04:44:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC