- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 14 May 2013 00:10:41 -0400
- 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