Re: [whatwg] onclose events for MessagePort

OK, so I gave this some thought and I and Olli managed to convince each
other that finding a solution to the problem of dispatching a generic
onclose event is impossible since there is no deterministic point in time
before a worker is GCed when we know that it will be GCed soon.

So with that behind us, how about we add an explicit event to be fired when
the other side of a message channel gets destroyed in a catastrophic way
which is not observable from the web content code running on that side,
such as a process crash for example?  The basic idea behind why this more
restricted proposal is useful is that barring the catastrophic failure
case, applications can detect the other cases why further communication may
be impossible (such as navigating away from the page) themselves and notify
the other side of the channel as desired -- it is only the catastrophic
termination case which is not detectable from content script.

How about we add another event named "channeldropped" (pending
bikeshedding) which is fired on a message port if the owner global context
of its entangled port is terminated in a catastrophic way?  Needless to
say, the event will be queued asynchronously with the termination of the
other side, and it will not be affected by garbage collection.

Thoughts?

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


On Tue, Oct 1, 2013 at 6:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Oct 1, 2013 at 11:13 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> > On 10/1/13 2:11 PM, Ian Hickson wrote:
> >>
> >> How often do we expect two tabs to be talking to each other though?
> >
> > Or a page to an out-of-process subframe?
>
> Or an out-of-process worker. I would think that in Chrome
> SharedWorkers can come from a separate process, though that might
> change if/when chrome switches to out-of-process iframes.
>
> / Jonas
>

Received on Wednesday, 9 October 2013 22:07:21 UTC