Re: Future feedback

On 17/05/13 8:52 AM, Sean Hogan wrote:
> 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?
>

Sorry. Meant to say "`setImmediate()` or some new function". Probably 
should be a new function because `clearImmediate()` isn't appropriate.