- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 22 Oct 2013 08:36:33 -0700
- To: Ehsan Akhgari <ehsan@mozilla.com>
- 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 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.
We could even expose a failAndUnpin function which rejects the promise.
This could be useful to enable the page to implement timeouts etc.
/ Jonas
Received on Tuesday, 22 October 2013 15:36:59 UTC