[whatwg] onclose events for MessagePort
simonp at opera.com
Thu Oct 10 01:48:15 PDT 2013
On Thu, 10 Oct 2013 08:58:52 +0200, Jonas Sicking <jonas at sicking.cc> wrote:
> On Wed, Oct 9, 2013 at 3:06 PM, Ehsan Akhgari <ehsan at mozilla.com> wrote:
>> 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
>> 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
>> 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,
>> as a process crash for example? The basic idea behind why this more
>> restricted proposal is useful is that barring the catastrophic failure
>> 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
>> 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,
>> event will be queued asynchronously with the termination of the other
>> and it will not be affected by garbage collection.
> I could see the GC case not being solvable.
> But is there a reason that we couldn't also fire the event if the
> other side is forcefully terminated through a navigation or a
> Worker.terminate() call?
Does navigation disentangle ports? I don't think it necessarily does, at
least per spec.
More information about the whatwg