Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 6:12 PM, Glenn Maynard wrote: > On Wed, Feb 9, 2011 at 8:39 PM, Jonas Sicking wrote: >> >> On Wed, Feb 9, 2011 at 5:26 PM, Glenn Maynard wrote: >> > Another related issue: what happens if a long-running number-cruncher >> > worker >> > keeps a database open while it works,

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 8:39 PM, Jonas Sicking wrote: > On Wed, Feb 9, 2011 at 5:26 PM, Glenn Maynard wrote: > > Another related issue: what happens if a long-running number-cruncher > worker > > keeps a database open while it works, to read data or output results? > > There's no API for sending

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 5:26 PM, Glenn Maynard wrote > > > On a related note, please see this statement from section 5.5 of the >> MessagePort spec: >> >> Authors are strongly encouraged to explicitly close >> MessagePort objects >> to disentangle them

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 5:26 PM, Glenn Maynard wrote: > Another related issue: what happens if a long-running number-cruncher worker > keeps a database open while it works, to read data or output results? > There's no API for sending versionchange events for IDBDatabaseSync, and it > doesn't fit in

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 5:05 PM, Drew Wilson wrote: > In some cases we leak them, yes (they live for the life of the parent > context) if the developer does not close them. Typically this is only when > you've cloned a MessagePort and sent the other end to a different process. > Trying to figure o

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 2:03 PM, Jonas Sicking wrote: > > 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. > Hmmm. That was certainly not the intent wh

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

In some cases we leak them, yes (they live for the life of the parent context) if the developer does not close them. Typically this is only when you've cloned a MessagePort and sent the other end to a different process. Trying to figure out if a port is reachable when the entangled port lives in a

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 11:05 AM, Drew Wilson 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 wh

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 2:05 PM, Drew Wilson 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 wh

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 11:20 AM, Jeremy Orlow wrote: > On Wed, Feb 9, 2011 at 11:05 AM, Drew Wilson 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 MessageP

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 11:05 AM, Drew Wilson 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 w

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

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 r

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 3:31 PM, Glenn Maynard wrote: > On Tue, Feb 8, 2011 at 4:01 PM, Jeremy Orlow wrote: >> >> I talked it over with Darin (Fisher), and he largely agreed with you guys. >>  I'll file a bug saying that after unload, all IDBDatabases attached to that >> document should be closed.

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 4:01 PM, Jeremy Orlow wrote: > I talked it over with Darin (Fisher), and he largely agreed with you guys. > I'll file a bug saying that after unload, all IDBDatabases attached to that > document should be closed. What happens if a database is open in a page in the back-f

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 3:31 PM, Glenn Maynard wrote: > On Tue, Feb 8, 2011 at 4:01 PM, Jeremy Orlow wrote: > >> I talked it over with Darin (Fisher), and he largely agreed with you guys. >> I'll file a bug saying that after unload, all IDBDatabases attached to that >> document should be closed.

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

I talked it over with Darin (Fisher), and he largely agreed with you guys. I'll file a bug saying that after unload, all IDBDatabases attached to that document should be closed. J On Tue, Feb 8, 2011 at 11:51 AM, ben turner wrote: > I'm actually fine with keeping the setVersion from proceeding

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On 2/8/2011 11:51 AM, ben turner wrote: I'm actually fine with keeping the setVersion from proceeding until the old database is collected. First, this is probably a bug in the web page, and the page should be fixed. Second, the new database that is waiting for setVersion to proceed will get an on

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

2011/2/8 Jeremy Orlow : > On Tue, Feb 8, 2011 at 10:36 AM, Jonas Sicking wrote: >> >> On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow wrote: >> > On Tue, Feb 8, 2011 at 3:36 AM, João Eiras wrote: >> >> >> >> > Unless by "certain GC behavior" mean >> >> >> >> I referred to >> >> >> >> # The only sol

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

I'm actually fine with keeping the setVersion from proceeding until the old database is collected. First, this is probably a bug in the web page, and the page should be fixed. Second, the new database that is waiting for setVersion to proceed will get an onblocked event, so the page should know tha

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 10:36 AM, Jonas Sicking wrote: > On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow wrote: > > On Tue, Feb 8, 2011 at 3:36 AM, João Eiras wrote: > >> > >> > Unless by "certain GC behavior" mean > >> > >> I referred to > >> > >> # The only solution I can think of is to require (

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow wrote: > On Tue, Feb 8, 2011 at 3:36 AM, João Eiras 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 >> >> Th

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 3:36 AM, João Eiras 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 > sp

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

> 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.

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 3:26 AM, Jonas Sicking wrote: > On Tue, Feb 8, 2011 at 3:20 AM, João Eiras wrote: >> On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking wrote: >>> On Tue, Feb 8, 2011 at 2:45 AM, João Eiras wrote: > The only solution I can think of is to require (or recommend) that >

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 3:20 AM, João Eiras wrote: > On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking wrote: >> On Tue, Feb 8, 2011 at 2:45 AM, João Eiras wrote: The only solution I can think of is to require (or recommend) that implementations run the garbage collector in a context after

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking wrote: > On Tue, Feb 8, 2011 at 2:45 AM, João Eiras 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 st

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 2:45 AM, João Eiras 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

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

> 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

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Mon, Feb 7, 2011 at 8:09 PM, Jeremy Orlow wrote: > We're currently implementing the onblocked/setVersion semantics and ran into > an interesting problem: if you don't call .close() on a database and simply > expect it to be collected, then you ever being able to run a setVersion > transaction i

[IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

We're currently implementing the onblocked/setVersion semantics and ran into an interesting problem: if you don't call .close() on a database and simply expect it to be collected, then you ever being able to run a setVersion transaction is at the mercy of the garbage collecter doing a collection.