- From: Sean Hogan <shogun70@westnet.com.au>
- Date: Fri, 17 May 2013 08:52:02 +1000
- 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