On Tue, May 14, 2013 at 7:30 PM, Mark Miller <erights at gmail.com> wrote:
> 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?

It's quite probably doable to modify the current solution. I'd
recommend talking to Rafael Weinstein, Olli Pettay and Anne van
Kesteren who designed and specified the current behavior.

/ Jonas

> 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

On Tue, May 14, 2013 at 7:30 PM, Mark Miller <erights at gmail.com> wrote:
> 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?

It's quite probably doable to modify the current solution. I'd
recommend talking to Rafael Weinstein, Olli Pettay and Anne van
Kesteren who designed and specified the current behavior.