On Wed, Jun 18, 2014 at 9:13 PM, Domenic Denicola < domenic@domenicdenicola.com> wrote: > [+Yehuda, +Raf] > > From: Jonas Sicking [mailto:jonas@sicking.cc] > > > On Thu, Jun 19, 2014 at 8:44 AM, Adam Klein <adamk@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
Received on Thursday, 19 June 2014 05:44:00 UTC