Re: Task Queues as a primitive

For what it's worth, TC39 is planning on taking up standardization of event
loop concurrency in ES7. We tentatively started to discuss it at the last
meeting, and it would be a good place for TC39/W3C coordination.

Yehuda Katz
(ph) 718.877.1325


On Mon, Jul 1, 2013 at 9:29 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> Man, another mailing list? This one looks fun. Cc'ing Mark Miller since I
> know he wants this.
>
> One issue is that setImmediate is about access to the "macrotasks" queue.
> This queue is also used by postMessage and MessageChannel.
>
> There is also the "microtasks" queue, used currently only by
> MutationObserver. I believe Object.observe is planned to land there.
>
> The difference, from a layman's perspective at least, seems to be that
> each event loop turn looks something like:
>
> - Run JS code
> - Run microtask queue
> - Do layout and IO stuff
> - Run macrotask queue.
>
> And I believe there are also differences regarding what happens with
> nested queue pushes, i.e. if I'm inside a microtask and push another
> microtask, does it executed immediately or do we wait for another event
> loop turn's microtask phase?
>
> Anyway, setImmediate is a great start for making things non-awkward. It's
> useful if you want to wait for CSS changes to apply. But ideally there
> would be a way to access the microtask queue directly as well, without
> creating pointless elements only so that you can mutate them and thus use
> MutationObserver to access the microtask queue indirectly. This is great
> for direct JS flow-control related use cases, like promises.
>
> In Node.js, this microtask-queue--accessing function is called
> `process.nextTick`, for what it's worth. (In their case there is no layout,
> but there is IO.)
>
> I think it's important in all this to focus on the user-facing
> consequences and not try to get bogged down in what the internal browser
> models are. Right now there are direct observable differences between the
> asynchronicity of MutationObserver versus the asynchronocity of
> setImmediate/postMessage/MessageChannel. Making it clear exactly how that
> works and giving users access to basic primitives for tapping into those
> sources of asynchronicity is what I think we should focus on.
>
> ________________________________________
> From: Marcos Caceres [w3c@marcosc.com]
> Sent: Monday, July 01, 2013 12:12
> To: François REMY
> Cc: public-nextweb@w3.org; Domenic Denicola
> Subject: Re: Task Queues as a primitive
>
> (Cc'd Domenic, as he has been pushing this for a while...)
>
>
> On Monday, July 1, 2013 at 4:37 PM, François REMY wrote:
>
> > > The HTML spec speaks a lot about task queues [1]
> > > and "spin the event loop" [2], but there are only
> > > limited ways for devs to hook into those today.
> > >
> > > Would be nice if there was some primitive that
> > > allowed JS developers to hook into the loop without
> > > relying on hacks like setTimeout and MutationObserver.
> > >
> > > It would also be nice to see what is in those task queues
> > > (ordering, etc) and in which order the task queues are
> > > processed.
> > >
> > > Thoughts?
> >
> > Browser will probably never let you look at what they're going to do
> next,
> > because that would reveal much of their internal behavior, may be
> decided in
> > function of what you're doing and how much time it took, and may change
> > between releases (and therefore causing bugs if you act based on this
> > information).
>
> True.
> >
> > However, it seems it's already possible to build a JS-based priority
> queue
> > by using the setImmediate()
>
>
> Note that this is IE only right now. But good to know at least someone
> here is using IE and watching what is going on in Microsoft land :)
>
> > hook and a custom Scheduler interface, as
> > demonstrated in WinJS 2.0 [1]. Basically, they're using priority bins to
> > influence the order of JS-based async tasks by managing them in a
> scheduler
> > that will act as a gateway from the native event loop to the JS waiting
> > tasks.
>
> Neat. Great to hear there is a proof of concept already running based on
> setImmidiate.
> > The source code of WinJS is available but I've not downloaded the 2.0
> > preview version so I can't give more insight about it (and, in
> particular,
> > if they used any other API than setImmediate to hook into the event
> queue).
> >
>
> Would be interesting to see. Can we get someone form Microsoft to join
> this list?
>
> BTW:
> Some related bugs (promises and ES related):
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22296#c7
>
> If we want this in Gecko:
> https://bugzilla.mozilla.org/show_bug.cgi?id=686201
>
> If we want this in Webkit:
> http://code.google.com/p/chromium/issues/detail?id=146172
>
> Kind regards,
> Marcos
>
>
>
>
>