- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 13 May 2013 21:05:10 -0700
- 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