Future feedback

Mark Miller erights at gmail.com
Tue May 14 19:30:03 PDT 2013


Is there any reason that this can't be modeled with the end-of-microtask
queue still being just one of many output queues? These observed mutations
would just queue notifications on the end-of-microtask queue. The
interleaving policy would be to always select an event from the end of
microtask queue first if it is non-empty. I.e., strict priority, decided at
the moment when the next turn is about to be started. Am I missing
something?


On Tue, May 14, 2013 at 7:08 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> Actually, mutation observers have some special behavior that only
> lasts until the end-of-microtask queue is empty. If you start
> observing the mutations that happen in a particular Node subtree
> rooted in a node A, you will be told about all mutations that happen
> in the nodes that were descendants of A until all end-of-microtask
> notifications have fired. So even if a node is removed from A and then
> modified, the observer is notified about those mutations as long as
> they happen before all end-of-microtask observers have fired.
>
> At least I think that's how I think it works. You'd have to check the
> spec for more details.
>
> Possibly this is something that can be changed though.
>
> / Jonas
>
> On Tue, May 14, 2013 at 5:59 PM, Mark Miller <erights at gmail.com> wrote:
> > AFAICT, the microtask queue is just another output queue, and the strict
> > priority of the microtask queue over other queues is just a policy
> choice of
> > which outgoing queue to service next. The input queue model could not
> > guarantee strict priority without creating a two level queue. The
> outgoing
> > queue model keeps this separate with no loss of generality. Cool.
> >
> >
>

-- 
  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130514/1d2eb233/attachment.html>


More information about the es-discuss mailing list