Re: Future feedback

On 17/05/13 12:30 AM, Boris Zbarsky wrote:
> 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.
>


So what would be the problem if `setImmediate()` just appended to the 
futures task source?