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

Re: [whatwg] onclose events for MessagePort

From: Ehsan Akhgari <ehsan@mozilla.com>
Date: Tue, 22 Oct 2013 12:31:05 -0400
Message-ID: <CANTur_6F4yb3TZi_CKD1xkNph-XfiyNEubi7DAKkawC8xTQCfg@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>, Ian Hickson <ian@hixie.ch>, Andrew Wilson <atwilson@google.com>, Gene Lian <clian@mozilla.com>
On Tue, Oct 22, 2013 at 11:36 AM, Jonas Sicking <jonas@sicking.cc> wrote:

>
> On Oct 21, 2013 6:08 PM, "Ehsan Akhgari" <ehsan@mozilla.com> wrote:
> >> 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.
>
> Or we expose a property which indicates if the other side has already
> dropped.
>
> Though this property+event pattern is actually exactly what a promise is.
> And a promise automatically provides the nice feature that it automatically
> calls you back if it has been resolved.
>
> So we could expose have:
>
> interface MessagePort {
>   ...
>   Promise pin();
>   void unpin(optional any value);
> };
>
> Rather than firing channeldropped we reject any promise returned from
> pin(). Once the caller receives an expected answer he/she calls unpin()
> which resolves the promise using whatever value is passed in and so the
> port becomes GCable again.
>
> When pin() is called again after the unpin call we create a new promise
> which again prevents the port from getting GCed.
>
This sounds good to me, if the usage of Promise is OK in HTML these days!

> We could even expose a failAndUnpin function which rejects the promise.
> This could be useful to enable the page to implement timeouts etc.
>
Hmm, I'm not sure if I understand this.  Can you please elaborate?

--
Ehsan
<http://ehsanakhgari.org/>
Received on Tuesday, 22 October 2013 16:32:16 UTC

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