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
On Wed, Feb 9, 2011 at 11:05 AM, Drew Wilson atwil...@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
On Wed, Feb 9, 2011 at 11:20 AM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Feb 9, 2011 at 11:05 AM, Drew Wilson atwil...@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
On Wed, Feb 9, 2011 at 2:05 PM, Drew Wilson atwil...@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
On Wed, Feb 9, 2011 at 11:05 AM, Drew Wilson atwil...@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
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
On Wed, Feb 9, 2011 at 2:03 PM, Jonas Sicking jo...@sicking.cc 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
On Wed, Feb 9, 2011 at 5:05 PM, Drew Wilson atwil...@google.com 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.
On Wed, Feb 9, 2011 at 5:26 PM, Glenn Maynard gl...@zewt.org 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
On Wed, Feb 9, 2011 at 8:39 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Feb 9, 2011 at 5:26 PM, Glenn Maynard gl...@zewt.org 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?
On Wed, Feb 9, 2011 at 6:12 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Feb 9, 2011 at 8:39 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Feb 9, 2011 at 5:26 PM, Glenn Maynard gl...@zewt.org wrote:
Another related issue: what happens if a long-running number-cruncher
worker
keeps
On Mon, Feb 7, 2011 at 8:09 PM, Jeremy Orlow jor...@chromium.org 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
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
On Tue, Feb 8, 2011 at 2:45 AM, João Eiras joao.ei...@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
On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 8, 2011 at 2:45 AM, João Eiras joao.ei...@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
On Tue, Feb 8, 2011 at 3:20 AM, João Eiras joao.ei...@gmail.com wrote:
On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 8, 2011 at 2:45 AM, João Eiras joao.ei...@gmail.com wrote:
The only solution I can think of is to require (or recommend) that
On Tue, Feb 8, 2011 at 3:26 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 8, 2011 at 3:20 AM, João Eiras joao.ei...@gmail.com wrote:
On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 8, 2011 at 2:45 AM, João Eiras joao.ei...@gmail.com wrote:
The only
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.
On Tue, Feb 8, 2011 at 3:36 AM, João Eiras joao.ei...@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
On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Feb 8, 2011 at 3:36 AM, João Eiras joao.ei...@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
On Tue, Feb 8, 2011 at 10:36 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Feb 8, 2011 at 3:36 AM, João Eiras joao.ei...@gmail.com wrote:
Unless by certain GC behavior mean
I referred to
# The only
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
2011/2/8 Jeremy Orlow jor...@chromium.org:
On Tue, Feb 8, 2011 at 10:36 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Feb 8, 2011 at 3:36 AM, João Eiras joao.ei...@gmail.com wrote:
Unless by certain GC behavior
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 Tue, Feb 8, 2011 at 3:31 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Feb 8, 2011 at 4:01 PM, Jeremy Orlow jor...@chromium.org 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
On Tue, Feb 8, 2011 at 3:31 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Feb 8, 2011 at 4:01 PM, Jeremy Orlow jor...@chromium.org 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
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.
27 matches
Mail list logo
