[whatwg] onclose events for MessagePort
ian at hixie.ch
Wed Dec 11 11:18:29 PST 2013
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
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 <
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg