- From: Sean Hogan <shogun70@westnet.com.au>
- Date: Tue, 14 May 2013 13:40:59 +1000
- 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? Sean
Received on Tuesday, 14 May 2013 03:41:27 UTC