Re: Future feedback

Le 14/05/2013 04:40, Sean Hogan a écrit :
> 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?
I'm a bit confused by terminology and don't know where to jump in in 
this thread, but I believe this message [1] is relevant. It suggests 
that the inner&outer event loop (or task/microtask) model is being 
considered for ES7 standardization.

Hope that helps,

David

[1] 
http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0167.html

Received on Tuesday, 14 May 2013 13:12:55 UTC