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
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC