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

Re: Future feedback

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 13 May 2013 21:05:10 -0700
Message-ID: <CA+c2ei-DiLNbe1YaOkruY7F_wTVwN6zcKFG0LMuXNvC=8_Ct0Q@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Sean Hogan <shogun70@westnet.com.au>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Mon, May 13, 2013 at 8:51 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/12/13 11:37 PM, Jonas Sicking wrote:
>> On Sun, May 12, 2013 at 7:31 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>>> Moreover the page can be reflowed between tasks.
>>> _ANY_ async solution will have this property.  What does it even mean to
>>> be
>>> async if you don't allow reflows in the meantime?
>> Work that is performed at end-of-microtask is sort of between fully
>> asynchronous and normal synchronous.
> Wait.  Are we talking about adding more things to the end-of-microtask
> checkpoint list, or about adding a way to directly post unthrottled tasks to
> the event loop?
> I'm actually a lot more ok with adding end-of-microtask stuff, not least
> because that will, I believe, trigger slow script dialogs and other user
> countermeasures if it takes too long.

To be clear. The spec currently defines the Future API to be
completely async. I.e. it currently doesn't trigger callbacks to
happen at end-of-microtask but rather uses "posts unthrottled to the
event loop".

However it is technically possible to change that to use additional
things to the end-of-microtask checklist.

We could also change this to do some form of throttling.

I don't have strong opinions either way. Sending to the event loop,
even unthrottled, definitely risks causing a lot of latency. On the
other hand using end-of-microtask could mean developers being forced
to worry about triggering slow-script dialogs.

/ Jonas
Received on Tuesday, 14 May 2013 04:06:07 UTC

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