W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 8 Feb 2011 10:36:22 -0800
Message-ID: <AANLkTikpqOAwJHAujbLh0y8LBDp8SBv1ZXE4mCT32sCR@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Joćo Eiras <joao.eiras@gmail.com>, public-webapps <public-webapps@w3.org>
On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Tue, Feb 8, 2011 at 3:36 AM, Joćo Eiras <joao.eiras@gmail.com> wrote:
>>
>> > Unless by "certain GC behavior" mean
>>
>> I referred to
>>
>> # The only solution I can think of is to require (or recommend) that
>> implementations run the garbage collector
>>
>> The GC is transparent and a spec cannot expect that it runs at
>> specific times or demand it.
>
> Yeah, Jonas.  We can't reasonably expect any behavior from the garbage
> collectors.  I can't think of any other precedent for this.  And as
> collectors become more complicated, doing a gc that catches _every_ piece of
> garbage is becoming harder or even impossible (not aware of any GC's where
> it is "impossible" in specific cases, but it wouldn't surprise me).  The v8
> guys simply won't let us do this.  :-)
> And saying that at the worst case your setVersion transaction will stall
> possibly forever just doesn't seem like a good solution either.

Huh? It seems like a very strange GC implementation that not only
doesn't allow you to do a full search for garbage, even
asynchronously, but then can't even guarantee that a given object will
eventually be freed.

I'm all for not relying on GC behavior, but not even relying on it to
collect garbage? That seems a bit extreme to me. It's also not a GC
strategy I've ever heard of, so yes, it would surprise me if there are
GC strategies out there that doesn't free up objects sooner or later.
How is that different from a GC strategy that is simply leaking?

> What if we made the default for onsetversion to be calling close?  I.e.
> instead of the close behavior being opt-out, it'd be opt-in?  I know we made
> a conscious decision originally of it being opt-in, but I don't see how
> that'll work.

This flips the model completely on its head since you're now forced to
implement a more advanced version upgrade strategies or suffer your
pages breaking.

The worst case scenario isn't even that bad IMHO. Say that you have a
GC strategy which truly never frees the unreferenced DB object. That
is no worse than the page simply holding a reference DB object and
making the version upgrade wait for the user to close old tabs.
Something that is bound to happen anyway if authors take the simple
path of not listening to "blocked" or "versionchange" events.

/ Jonas
Received on Tuesday, 8 February 2011 18:38:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT