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

Re: Future feedback

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 14 May 2013 00:10:41 -0400
Message-ID: <5191B941.1030707@mit.edu>
To: Jonas Sicking <jonas@sicking.cc>
CC: Sean Hogan <shogun70@westnet.com.au>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 5/14/13 12:05 AM, Jonas Sicking wrote:
> 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".

Sure.  We have that with other things like postMessage as well.

But the point is that as far as I can tell nothing actually requires 
futures (or postMessage) to be unthrottled, and if UAs decide they need 
to be throttled they can be (e.g. the entire DOM manipulation task 
source can be throttled relative to user events if the UA wants to, as 
far as I can tell).

> I don't have strong opinions either way. Sending to the event loop,
> even unthrottled, definitely risks causing a lot of latency.

I think it's worth keeping in mind that in the spec, unlike some browser 
implementations there is no "the" event loop.  There are several 
different task sources which imply no ordering guarantees wrt each 
other.  The choice of which task source a given set of tasks will use is 
in fact an important part of the design of whatever functionality 
produces those tasks...

As long as whatever things might get abused are not using the same task 
sources as things we know we don't want to delay (like processing of the 
"close this tab, for crying out loud" user event), we're ok: we can 
always throttle those task sources as needed in the future.

-Boris
Received on Tuesday, 14 May 2013 04:11:59 UTC

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