- From: Andrew Wilson <atwilson@google.com>
- Date: Fri, 11 Oct 2013 10:37:43 +0200
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Ehsan Akhgari <ehsan@mozilla.com>, WHAT Working Group <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>, Gene Lian <clian@mozilla.com>, Ian Hickson <ian@hixie.ch>, Jonas Sicking <jonas@sicking.cc>
On Fri, Oct 11, 2013 at 10:18 AM, Anne van Kesteren <annevk@annevk.nl>wrote: > On Fri, Oct 11, 2013 at 9:38 AM, Andrew Wilson <atwilson@google.com> > wrote: > > *"or while there exists an event listener on either port for the > > channeldropped event."* > > Once you do that you basically rely on the developer to handle GC and > you'll end up with memory leaks instead. > > Agreed. I'm just pointing out that language/behavior like this is basically required if you're going to support a channeldropped event that can be spontaneously generated even on ports that have no live external references. To ameliorate this, you could say that the ports are only kept alive in the case that they have different owners (if I create a port and keep both ends with the same owner, then you'll never need to generate a channeldropped event and you can freely free them whenever there are no active references/pending events). As a data point/implementation note: Chrome already leaks ports whose entangled endpoints live in separate processes. It's just too hard to do the cross-process GC required to guarantee that both sides are unreachable. That's one reason why the spec states that it's best practice to explicitly close MessagePorts: Authors are strongly encouraged to explicitly close MessagePort<http://www.w3.org/TR/webmessaging/#messageport> objects to disentangle them, so that their resources can be recollected. Creating many MessagePort <http://www.w3.org/TR/webmessaging/#messageport> objects and discarding them without closing them can lead to high memory usage.
Received on Friday, 11 October 2013 08:38:11 UTC