W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] onclose events for MessagePort

From: Simon Pieters <simonp@opera.com>
Date: Thu, 10 Oct 2013 10:48:15 +0200
To: "Ehsan Akhgari" <ehsan@mozilla.com>, "Jonas Sicking" <jonas@sicking.cc>
Message-ID: <op.w4qdepxiidj3kv@simons-macbook-pro.local>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>, Ian Hickson <ian@hixie.ch>, Gene Lian <clian@mozilla.com>
On Thu, 10 Oct 2013 08:58:52 +0200, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Oct 9, 2013 at 3:06 PM, Ehsan Akhgari <ehsan@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  
>> 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.
>
> 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.

-- 
Simon Pieters
Opera Software
Received on Thursday, 10 October 2013 08:48:47 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:11 UTC