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 03:28:59 -0800
Message-ID: <AANLkTimvpru7+rZ4hV9Hzd5kY4uHcrh3Myw05oFh9BrT@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:26 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Tue, Feb 8, 2011 at 3:20 AM, Joćo Eiras <joao.eiras@gmail.com> wrote:
>> On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> On Tue, Feb 8, 2011 at 2:45 AM, Joćo Eiras <joao.eiras@gmail.com> wrote:
>>>>> The only solution I can think of is to require (or recommend) that
>>>>> implementations run the garbage collector in a context after firing
>>>>> the "versionchange" event if the database still isn't closed. This
>>>>> should be a rare occurrence simply because setVersion should be rare.
>>>>
>>>> That would be a hack in the implementation and a hack in the spec.
>>>
>>> Why? And what are you suggesting instead?
>>
>> Don't have a solution, but expecting certain GC behavior on a
>> specification is far from sane.
>
> No one is suggesting that. I'll also point out that even if the
> implementation doesn't GC the object immediately things will still
> work fine. You'll just receive the "success" event later, and possibly
> also a "blocked" event while waiting. As I'm sure you already know.

Unless by "certain GC behavior" mean "free objects that are no longer
used". If that is indeed what you meant then we'll have to agree to
disagree what is "far from sane".

/ Jonas
Received on Tuesday, 8 February 2011 11:29:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:16 UTC