W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Future feedback

From: Sean Hogan <shogun70@westnet.com.au>
Date: Fri, 17 May 2013 08:52:02 +1000
Message-ID: <51956312.6060504@westnet.com.au>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: David Bruant <bruant.d@gmail.com>, Jonas Sicking <jonas@sicking.cc>, "public-script-coord@w3.org" <public-script-coord@w3.org>
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?
Received on Thursday, 16 May 2013 22:52:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC