Re: Future feedback

On 5/16/13 6:04 AM, Sean Hogan wrote:
> On 16/05/13 2:43 PM, Boris Zbarsky wrote:
>> 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.

Of course the UA is free to do that.

What you just described is _exactly_ yielding to the event loop, as far 
as I can tell.

Or in formal spec language in the terms that the whatwg/html5 specs use 
it would go like so:

1)  then() happens off a task.
2)  Such tasks use the "future/promise/thenable task source".

So the model is that the task is placed in the f/p/t task source, the UA 
goes back to the event loop, picks a task source to service, and 
services it.  Now your description corresponds to:

   Surely the UA is free to prioritize the f/p/t task source over other
   task sources for some limited amount of time before servicing other
   task sources.

which is what task source prioritization is all about anyway, of course.

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

Ah.  Well, with a separate futures task source the answer is "depends on 
what other task sources have tasks and how the UA is prioritizing them". 
  The separate task source is good for preventing abuse in that it could 
be run with high priority for a bit, then have the priority throttled 
back if it threatens to hog the event loop...  The answer would then be 
"0ms" in the high-priority mode and probably closer to "10+ms" once 
you've been throttled.  Make sense?


Received on Thursday, 16 May 2013 14:31:22 UTC