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