On Fri, Jun 6, 2014 at 5:51 PM, Jonas Sicking <jo...@sicking.cc> wrote:

> On Thu, Jun 5, 2014 at 12:59 PM, Joshua Bell <jsb...@google.com> wrote:
> > case 1:
> >
> >   var tx;
> >   Promise.resolve().then(function() {
> >     tx = db.transaction(storeName);
> >     // tx should be active here...
> >   }).then(function() {
> >     // is tx active here?
> >   });
> >
> > For case 1, ISTM that "yes" matches the IDB spec, since control has not
> > returned to the event loop while the microtasks are running.
> Implementations
> > appear to agree.
>
> Yes. I believe that this is what the spec currently calls for.
>
> However I think it would actually be good to change the spec to say
> that the transaction is closed at the end of the current microtask.
>
> When we originally designed microtasks for Mutation Observers, one of
> the goals was to ensure that there were not accidental
> interdependencies between different event handlers to the same event.
> By flushing end-of-microtask work after each event handler you ensure
> that each event handler gets a clean slate.
>
> I realize that this is a backwards-incompatible change. However it
> seems pretty unlikely to break any existing content. So it'd be nice
> to give it a try.


While I agree that the original microtask intent would suggest we change
this, and I concur that it seems unlikely to break content, I worry about
the spec and implementation complexity that would be incurred by having to
support the notion of "at the end of the current microtask". It suggests
one of:

1. A new task queue, which runs after microtasks (nanotasks?)
2. The ability to put tasks at the start of the microtask queue rather than
at the end

(1) seems like a bad idea for a variety of reasons, not least of which that
it would soon lead us to need picotasks once an actor other than IDB saw a
need for it.

(2) strikes me as just plain hard to reason about. And again, if anyone
other than IDB tried to use that capability, it would become problematic.

Code running at end-of-microtask already has to deal with being in a
slightly different environment than "normal" event-handling code. I think
it might be worth avoiding additional complexity to make this quirk one of
those caveats.

- Adam

(resending from correct address, a dup may show up at some point)

Reply via email to