- From: Sean Hogan <shogun70@westnet.com.au>
- Date: Fri, 17 May 2013 09:16:59 +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 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.
Received on Thursday, 16 May 2013 23:17:29 UTC