Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 11:05 AM, Drew Wilson <atwilson@google.com> wrote:
> This discussion reminds me of a similar issue with MessagePorts. The
> original MessagePort spec exposed GC behavior through the use of onclose
> events/closed attributes on MessagePorts. It turns out that on Chromium,
> there are situations where it's very difficult for us to GC MessagePorts (a
> port's reachability depends on the reachability of the entangled port on an
> entirely separate process), and so we just don't.
> My concern is that there may be situations like this with IDB - if at some
> point it's possible for events to be fired on an IDB instance (if we support
> triggers), you'll have a situation where the reachability of an IDB instance
> may depend on the reachability of that same DB in other processes. The net
> effect is that on multi-process/multi-heap platforms, we may not be able to
> GC databases, while on other platforms (which have a unified heap) we will
> be able to GC them. This will end up being a source of cross-browser
> incompatibility, because code will work just fine on platforms that are able
> to deterministically GC databases, but then will break on other platforms
> that cannot.
> (As an aside, Jeremy mentions that there may already be situations where we
> cannot GC databases today - I don't know the spec well enough to comment,
> though, so perhaps he can elaborate).

I definitely agree that if there could be events fired at the
IDBDatabase instance, and there are event listeners attached to it,
then you shouldn't GC the instance. This is similar to how you
shouldn't GC <img> elements which are still loading images and have an
onload handler attached.

That seems no different from script holding a strong reference to the
instance though, so it's a situation the implementation has to deal
with anyway (by firing a "blocked" event at the setVersion request and
waiting for the user to close the tab).

> In any case, I don't think that IDB should be the first place in the entire
> web platform where we expose GC behavior to clients.

For what it's worth, shared workers already expose GC behavior. You'll
get a already-existing shared worker, or a new one will be created,
depending on if GC has collected the worker or not.

Not saying that this is great, just pointing out that this is the case.

/ Jonas

Received on Wednesday, 9 February 2011 22:04:47 UTC