[whatwg] onclose events for MessagePort

[Ehsan Akhgari]

On Mon, Oct 21, 2013 at 3:19 AM, Andrew Wilson <atwilson at google.com> wrote:

>
>
>
> On Sat, Oct 19, 2013 at 2:26 AM, Jonas Sicking <jonas at 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.
>

Yeah, you're right, sorry for overlooking this the first time around!


>  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?
>

I think we may need to mandate that a "channeldropped" eventis fired when
you register a handler on a port with the other side having already crashed.

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>