Re: [whatwg] onclose events for MessagePort

On Thu, Oct 10, 2013 at 5:20 PM, Ehsan Akhgari <ehsan@mozilla.com> wrote:
>
>
> Why would they expect that?  Storing a reference to a port object on a
> parent doesn't change the owner of the port.  (I agree that this can be a
> bit confusing if authors are not familiar with MessagePorts, but this is
> part of the semantics of the ports as currently specified, and I don't
> think the channeldropped event proposal changes the amount of confusion
> here.
>

Chrome, at the very least, doesn't do this currently (doesn't disentangle
the port when the owner is navigated) and I think it would surprise
developers that a reference to a port is insufficient to keep it alive (and
that you have to explicitly window.postMessage() that port to a
window/iframe to hand off ownership instead of doing it through Javascript).

However, I don't feel that strongly about this - it's a reasonable (and,
perhaps, even technically correct) interpretation of the spec ; I just
wanted to point out that this entails a change in the current behavior, at
least in some UAs.

On Thu, Oct 10, 2013 at 5:43 PM, David Barrett-Kahn <dbk@google.com> wrote:
>
>
> Why is revealing when garbage collection happens such a terrible thing
> anyway?  Java does it...
>

Because it's a source of cross-browser incompatibility since the GC
behavior of different user agents differs greatly. In fact, there's no
requirement in any spec that a browser ever do GC. As an example, there are
cases in Chrome currently where we explicitly leak MessagePorts because
it's too difficult to determine reachability of entangled ports with JS VMs
running across multiple processes, so apps that were expecting
onchanneldropped events based on GC would break in Chrome in these cases.

I recognize that there's value in tracking connected status - I'm just
saying we need to be careful not to tie it to something unreliable like GC.
Tying it to something else (like when the owning document/worker is
discarded, or the associated process shuts down/crashes) is more
deterministic.

Received on Thursday, 10 October 2013 16:36:16 UTC