W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] onclose events for MessagePort

From: Andrew Wilson <atwilson@google.com>
Date: Mon, 21 Oct 2013 09:19:15 +0200
Message-ID: <CAArhhis4iLYD3YvK+4U69=66PzmuCGctKbccE91qoehdDWqB=Q@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>, Gene Lian <clian@mozilla.com>, Ian Hickson <ian@hixie.ch>, Ehsan Akhgari <ehsan@mozilla.com>
On Sat, Oct 19, 2013 at 2:26 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> What I think might work is to say that as long as a "channeldropped"
> event listener is registered with a port, that is equivalent to
> holding a strong reference to the port. I.e. that prevents the channel
> from being GCed. Even if no references are held to either port.
> In other words, we'd give up 3, but only when 2 is actively used.

Agreed - this was my proposal here:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-October/041068.html in
response to your earlier email.

> We would also need to define that the "channeldropped" event is never
> fired on a port if that port's *owning* window has been navigated away
> from. Otherwise we could *never* GC a channel between two windows that
> has "channeldropped" registered on either side.
Makes sense, although I'm a bit fuzzy about the rules around MessagePorts
and window navigation (for example, if I navigate a window, is all content
in that window now shutdown/discarded, even though I could in theory get
back to the window by immediately clicking "back")?

> So the expectation is that a caller should only register a
> "channeldropped" event if it's actively waiting for a response from
> that thread. It's not something that you should register when creating
> the port and then never unregister. Having a "channeldropped" event
> listener registered can cause a whole worker thread to be kept alive
> longer than it otherwise would.

How does this work - imagine that I have a reference to a MessagePort, but
I'm not actively waiting for any response on the port so I don't have a
channeldropped event listener.

Now, the remote side of the port crashes. I send a message on the port and
add a "channeldropped" event handler - are you saying that adding a
"channeldropped" event handler should trigger a channeldropped event if the
other side has already crashed? If not, then how do I find out that the
channel has been dropped if I don't keep the event handler registered all
the time?
Received on Monday, 21 October 2013 07:19:43 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:12 UTC