Re: Future feedback

On 16/05/13 2:43 PM, Boris Zbarsky wrote:
> On 5/16/13 12:32 AM, Sean Hogan wrote:
>> Future.accept()
>> .then(function() {
>>      task1();
>>      task2();
>> })
>> .then(function() {
>>      task3();
>> });
>>
>> Assuming a **best-case scenario**
>
> Define "best-case"?  What are the criteria?
>
> As far as how it behaves in practice, I believe some current UAs could 
> do a reflow between task1 and task2 there, and in fact might do it 
> while task1 is running.  Most current UAs would definitely not do 
> anything between task1 and task2, since those run sync right after 
> another.
>
> The question is what happens with then(), right?  It seems to me that 
> either it has to yield to the general event loop (and allow reflow to 
> happen sometimes) or it needs to be subject to things like slow-script 
> dialogs.  Given that as I understand the point of this setup is to 
> encapsulate fundamentally async computations, yielding to the event 
> loop makes the most sense to me...
>


Surely the UA is free to queue (tasks such as) Future callback 
processing for immediate execution, and just pause the queue if it needs 
to yield. I could emulate a time-restricted micro-task queue in a few 
lines of JS. But the UA is in the better position to know when such a 
queue should be paused.


> Note that just because reflow _can_ happen between task2 and task3 
> doesn't mean it _will_.  UAs do try to not reflow too often and all.
>
>> 3. What is the timing interval between task2 and task3? Milliseconds is
>> fine.
>
> Seems like "milliseconds unless something else hogs the event loop" 
> should be trivial to achieve: you can get that right now with 
> setTimeout, which is not throttled for a bit, then throttles to 4ms.
>


Sorry - I meant an answer to the closest millisecond. That is, closest 
to 0ms, 1ms, 2ms ...

Received on Thursday, 16 May 2013 10:05:18 UTC