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

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

From: Jeremy Orlow <jorlow@chromium.org>
Date: Tue, 8 Feb 2011 09:26:46 -0800
Message-ID: <AANLkTinoWeOZ8o-1skhyJxhwLK=QapFNd4Td6sjTEG3V@mail.gmail.com>
To: Joćo Eiras <joao.eiras@gmail.com>
Cc: public-webapps <public-webapps@w3.org>
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.

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.

J
Received on Tuesday, 8 February 2011 17:27:38 GMT

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