[whatwg] onclose events for MessagePort

Andrew Wilson atwilson at google.com
Fri Oct 11 01:37:43 PDT 2013

On Fri, Oct 11, 2013 at 10:18 AM, Anne van Kesteren <annevk at annevk.nl>wrote:

> On Fri, Oct 11, 2013 at 9:38 AM, Andrew Wilson <atwilson at 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.

More information about the whatwg mailing list