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

Reply via email to