Re: Task Queues as a primitive

I totally agree that we want to expose the event loop better. Having
implemented a polyfill for this in Ember (the Ember "Run Loop") I feel
strongly that getting this right (in particular, avoiding interleaving
where possible) is critical to getting the best (or in some cases, even
good enough) performance out of this system.

Yehuda Katz
(ph) 718.877.1325


On Fri, Jul 12, 2013 at 7:30 AM, Marcos Caceres <w3c@marcosc.com> wrote:

> Data point:
> The case for setImmediate()
>
> http://www.nczonline.net/blog/2013/07/09/the-case-for-setimmediate/
>
> --
> Marcos Caceres
>
>
> On Tuesday, 2 July 2013 at 14:15, Yehuda Katz wrote:
>
> > Something like this: `setImmediate` is an API that puts a task in an
> early queue that will run once the current program has run to completion.
> It runs before queues for other such APIs, like Object.observe, Mutation
> Observers, etc.
> >
> > Yehuda Katz
> > (ph) 718.877.1325
> >
> > On Tue, Jul 2, 2013 at 9:04 AM, Marcos Caceres <w3c@marcosc.com (mailto:
> w3c@marcosc.com)> wrote:
> > >
> > >
> > >
> > > On Tuesday, 2 July 2013 at 02:45, Yehuda Katz wrote:
> > >
> > > > 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.
> > >
> > > What do you see as the role of setImmediate() in that? Has there been
> some kind of API proposal for the event loop stuff. Any pointers would be
> greatly appreciated.
> > >
> > > With regards to TC39/W3C coordination, what could this group do to
> help? or should we just keep a holding pattern. I guess having you be part
> of both orgs is already super helpful.
>
>
>
>