Re: Indexed DB Transactions vs. Microtasks

2014-06-19 Thread Anne van Kesteren
On Thu, Jun 19, 2014 at 7:48 AM, Domenic Denicola
dome...@domenicdenicola.com 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

2014-06-19 Thread Adam Klein
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


Re: Indexed DB Transactions vs. Microtasks

2014-06-18 Thread Adam Klein
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)


Re: Indexed DB Transactions vs. Microtasks

2014-06-18 Thread Jonas Sicking
On Thu, Jun 19, 2014 at 8:44 AM, Adam Klein ad...@google.com 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

2014-06-18 Thread Domenic Denicola
[+Yehuda, +Raf]

From: Jonas Sicking [mailto:jo...@sicking.cc] 

 On Thu, Jun 19, 2014 at 8:44 AM, Adam Klein ad...@google.com 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

2014-06-18 Thread Adam Klein
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 ad...@google.com 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

2014-06-18 Thread Domenic Denicola
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

2014-06-06 Thread Jonas Sicking
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.

 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

2014-06-05 Thread Ian Hickson
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.   `._.-(,_..'--(,_..'`-.;.'