Re: Indexed DB Transactions vs. Microtasks
On Fri, Jun 6, 2014 at 5:51 PM, Jonas Sicking wrote:
> On Thu, Jun 5, 2014 at 12:59 PM, Joshua Bell 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
Re: Indexed DB Transactions vs. Microtasks
On Thu, Jun 19, 2014 at 7:48 AM, Domenic Denicola wrote: > Hmm, it seems pretty related to me. In particular if we say that the IDB > microtask bucket always runs after all other microtask buckets, doesn't that > achieve the goals? He said after each microtask (singular). -- http://annevankesteren.nl/
RE: Indexed DB Transactions vs. Microtasks
From: ad...@google.com [mailto:ad...@google.com] On Behalf Of Adam Klein > This seems orthogonal to bucketing. The IDB transaction deactivation step > isn't a sort of work that we'd want to bucket (as I argued in my previous > message, treating this IDB work as a task leads down some bad roads) Hmm, it seems pretty related to me. In particular if we say that the IDB microtask bucket always runs after all other microtask buckets, doesn't that achieve the goals? It's essentially a generalization of your (1), by putting them into a larger conceptual framework. More explicitly, it achieves (1) since the last bucket in the microtask list is essentially "nanotasks". But if we later decided something else needed to run after IDB (your "picotasks"), then we could demote IDB to second-to-last bucket without having to overhaul the overall model.
Re: Indexed DB Transactions vs. Microtasks
On Wed, Jun 18, 2014 at 9:13 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > [+Yehuda, +Raf] > > From: Jonas Sicking [mailto:jo...@sicking.cc] > > > On Thu, Jun 19, 2014 at 8:44 AM, Adam Klein wrote: > >> 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 > > > > I was just thinking to hardcode this into the algorithm that's run at > the end of the microtask. Note that closing the transaction never runs > code, which means that very little implementation complexity is needed. > > > I definitely agree that both of the above options are pretty > unattractive. > > This recalls Yehuda's proposal for a "bucketed" microtask queue. It seems > like this is a very strong argument for it. > This seems orthogonal to bucketing. The IDB transaction deactivation step isn't a sort of work that we'd want to bucket (as I argued in my previous message, treating this IDB work as a task leads down some bad roads); as Jonas says, we would actually want to hardcode it as a thing that "just happens" after each microtask is run (an idea that would have unappealing consequences for the Chromium implementation of microtasks, but one which I'll mull over). - Adam
RE: Indexed DB Transactions vs. Microtasks
[+Yehuda, +Raf] From: Jonas Sicking [mailto:jo...@sicking.cc] > On Thu, Jun 19, 2014 at 8:44 AM, Adam Klein wrote: >> 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 > > I was just thinking to hardcode this into the algorithm that's run at the end > of the microtask. Note that closing the transaction never runs code, which > means that very little implementation complexity is needed. > I definitely agree that both of the above options are pretty unattractive. This recalls Yehuda's proposal for a "bucketed" microtask queue. It seems like this is a very strong argument for it.
Re: Indexed DB Transactions vs. Microtasks
On Thu, Jun 19, 2014 at 8:44 AM, Adam Klein wrote: > 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 I was just thinking to hardcode this into the algorithm that's run at the end of the microtask. Note that closing the transaction never runs code, which means that very little implementation complexity is needed. I definitely agree that both of the above options are pretty unattractive. / Jonas
Re: Indexed DB Transactions vs. Microtasks
On Fri, Jun 6, 2014 at 5:51 PM, Jonas Sicking wrote:
> On Thu, Jun 5, 2014 at 12:59 PM, Joshua Bell 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)
Re: Indexed DB Transactions vs. Microtasks
On Thu, Jun 5, 2014 at 12:59 PM, Joshua Bell 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.
> case 2:
>
> var tx = db.transaction(storeName);
> var request = tx.objectStore(storeName).get(0);
> request.onsuccess = function() {
> // tx should be active here...
> Promise.resolve().then(function() {
> // is tx active here?
> });
> };
>
> For case 2, it looks like implementations differ on whether microtasks are
> run as part of the event dispatch. This seems to be outside the domain of
> the IDB spec itself, somewhere between DOM and ES. Anyone want to offer an
> interpretation?
I agree that this falls outside of the domain of the IDB spec. I admit
I would have preferred if the .then handler never sees an active
transaction, rather than have that depend on if resolving the promise
happens synchronously or asynchronously...
I don't know how to define that in a sane manner though.
And I have no idea how Firefox's current implementation appears to
manage to accomplish that.
/ Jonas
Re: Indexed DB Transactions vs. Microtasks
On Thu, 5 Jun 2014, Joshua Bell wrote:
>
> For case 2, it looks like implementations differ on whether microtasks
> are run as part of the event dispatch. This seems to be outside the
> domain of the IDB spec itself, somewhere between DOM and ES. Anyone want
> to offer an interpretation?
Event dispatch (specifically, the handling of "onsuccess", as opposed to
addEventListener('success') which is similar but defined in other specs)
is something that HTML tries to define. Assuming IndexDB defers to HTML's
definition of "event handler IDL attribute", then you go through the
"event handler processing algorithm", which calls "jump to a code
entry-point" which calls "clean up after running a callback" which calls
"perform a microtask checkpoint" which, once ES and HTML have been made to
play nice, invokes the promise callbacks, all before the task that fired
the event handler has returned to the event loop. And once it does return
to the event loop, the next major thing _it_ does is "perform a microtask
checkpoint" anyway.
HTH.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Indexed DB Transactions vs. Microtasks
Playing with Promise wrappers for IDB, the intersection of IDBTransaction's
|active| state and microtask execution came up. Here are a couple of
interesting cases:
case 1:
var tx;
Promise.resolve().then(function() {
tx = db.transaction(storeName);
// tx should be active here...
}).then(function() {
// is tx active here?
});
case 2:
var tx = db.transaction(storeName);
var request = tx.objectStore(storeName).get(0);
request.onsuccess = function() {
// tx should be active here...
Promise.resolve().then(function() {
// is tx active here?
});
};
In Chrome 35, the answers are "no", "no". This is because it was a
non-conforming Promise implementation, with the Promise callbacks not run
as microtasks. This was addressed in 36, so please disregard this behavior.
In Chrome 36, the answers are "yes", "yes".
In Firefox 29, the answers are "yes", "no".
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.
For case 2, it looks like implementations differ on whether microtasks are
run as part of the event dispatch. This seems to be outside the domain of
the IDB spec itself, somewhere between DOM and ES. Anyone want to offer an
interpretation?
