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

Re: Future feedback

From: Sean Hogan <shogun70@westnet.com.au>
Date: Tue, 14 May 2013 13:40:59 +1000
Message-ID: <5191B24B.6090401@westnet.com.au>
To: Jonas Sicking <jonas@sicking.cc>
CC: Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 13/05/13 1: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. Since it runs as part of the same
> task it means that reflows can't happen before the end-of-microtask
> work happens.
> This means that you get some advantages of asynchronous code, such as
> not having to worry about being in an inconsistent state due to code
> higher up on the call stack being half-run. And likewise you don't
> have to worry about not messing up code higher up on the callstack
> which didn't expect to have things change under it.
> But it also means that you are missing out of some of the advantages
> of asynchronous code, such as you still have to worry about hogging
> the event loop for too long and thus not processing pending UI events
> from the user.

Thanks for interpreting my comment.

As I asked Boris, how could "queuing a task" be abused more than DOM 
Future could be?

Received on Tuesday, 14 May 2013 03:41:27 UTC

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