[whatwg] onclose events for MessagePort

[Ian Hickson]

On Tue, 10 Dec 2013, Ehsan Akhgari wrote:
> On Fri, Dec 6, 2013 at 8:22 PM, Ian Hickson <ian at hixie.ch> wrote:
> > 
> > It doesn't fire when a port's owner document is navigated away from, 
> > because that would prevent the page from being bfcached, which we try 
> > hard to avoid. For pages it's reasonably easy to just hook into the 
> > document's onunload handler and send a message to all ports then.
> >
> > It doesn't fire when a port's owner worker terminates, because it 
> > seems weird to fire it sometimes but not others when the owner closes. 
> > For dedicated workers there is unfortunately no unload handler, 
> > because that would similarly prevent the bfcache... Not sure what the 
> > right thing to do is there. We don't want to expose the bfcache 
> > eviction model either.
> 
> With my implementer hat on, the bfcache prevention problem is fine with 
> us. There are already many other reasons for which we decide to not put 
> a page in the bfcache--

Right, but isn't that considered a problem?


> and given the fact that currently a solution for the case where the page 
> is navigated away from will need to register an unload event handler 
> (which also disables bfcache) we will be in no worse spot than we are 
> today.

For pages that register the unload handler, sure. But if we do this, we 
block _all_ pages that use MessagePorts from going into the bfcache, 
because there's no way to know if the other side has a registered handler 
for the event or not when you are navigated. I suppose you could 
optimistically bfcache it and then if any of the entangled ports report 
back that they had a listener for 'error' then you throw away the page, 
but that would actually bring about yet another problem, which is that we 
generally try very hard to make having a listener or not having a listener 
be otherwise indistinguishable. It would also actually require a 
synchronous IPC, or at least blocking on IPC in the case that the page you 
navigated to immediately called history.back().


> I actually think that in Gecko won't be interested in implementing the 
> current spec for the close event since it won't solve our use case if 
> the other side happens to crash before we manage to register an onclose 
> handler.  The proposal which we're currently interested in implementing 
> is something along the lines of < 
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-October/041250.html>. 

The problem with an elaborate proposals such as this one is that in UAs 
that never need to worry about this (e.g. because they are single-process, 
or they are desktop UAs that don't need to worry about a kill-happy OOM 
handler in the kernel and that are stable enough that they crash 
sufficiently rarely that they don't care to worry about this), the API is 
something that still needs to be implemented, even if it's a no-op, and so 
the more complicated the API the more wasted work it is.

The event approach has the advantage that a no-op implementation need be 
nothing more than an IDL attribute event handler, something which should 
be a trivial burden given how common adding those is on the platform.

Now, we could still handle your use case (Ehsan and I chatted about this 
on IRC yesterday; the problem is what to do if, for instance, a port is 
being passed across multiple processes, and the OOM killer is essentially 
chasing the end-point, killing processes before they can inform the final 
recipient that the source has itself been killed). There's two obvious 
ways to do it; one is an attribute, the other is to just send the event 
whenever a MessagePort is created if it's other side is already known to 
be crashed. The one with the least impact on no-op UAs is the event; that 
would also have the advantage of meaning you didn't have to know 
synchronously that the port was damaged goods. The problem with the 
attribute is that you might not get the notification that the port is 
ill-fated until after you receive the port, even though the 'error' event 
has already fired (or tried to fire) in some other process.

So my proposal to handle this would be to send another 'error' event, 
basically any time you create a MessagePort that's entangled with someone 
who has crashed already.


> One nice property of that proposal with regards to the bfcache issue is 
> that we will only need to disable the bfcache while the port is pinned, 
> and we are fine with disabling the bfcache in that case.

That would require synchronous IPC at navigation time, which seems 
suboptimal at best.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'