W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2012

Re: DataChannels API

From: Randell Jesup <randell-ietf@jesup.org>
Date: Thu, 13 Sep 2012 02:25:47 -0400
Message-ID: <50517C6B.6070803@jesup.org>
To: public-webrtc@w3.org
CC: Patrick McManus <mcmanus@ducksong.com>, Jason Duell <jduell@mozilla.com>
On 9/12/2012 10:21 AM, Adam Bergkvist wrote:
> Hi
>
> I want to bring up another issue while we're discussing the DataChannel.
>
> Garbage collection
> --------------------------------------------------------
> When should a DataChannel instance be garbage collected?
>
> Proposal: Align behavior with WebSockets. This means that if the
> readyState is "connecting", "open", or "closing" and at least one event
> listeners is registered for any of the open, message, error or close
> events, then DataChannel must not be garbage collected. (In case the
> initial reference is lost, a reference to the DataChannel object can be
> obtained from the evt.target property of an event fired on the
> DataChannel.)

I've been assuming normal GC rules: if anything has a reference to it, 
it should not be GC'd.  If you drop all references to a DataChannel, it 
may be GC'd; if so it will attempt to close itself before going away.

Even if the state is "closed", we would not let it be GC'd if a 
reference still exists of course.  Your comment above probably meant to 
include this proviso.

So, given that, your suggestion would be that if it closed and there are 
no direct references (only listeners), then it can be disconnected from 
the listeners and made available for GC when the refcount goes to 0. 
Note that pending events would have a reference.  (This is a slight 
simplification for discussion.)

The alternative is to allow it to be GC'd if all refs to the DataChannel 
object are dropped; after that you may or may not get callbacks.  (We 
also could key off refcnt == 0 and Close() and nuke all listeners, which 
would provide a more consistent (though slightly different than 
WebSockets) result.)

Does anyone know why the WebSocket API allows ghost channels that exist 
only to service their listeners?  I'll note that if they don't get an 
event, you can't ever close them or do anything about them, since you 
need an event to get a reference.  It may slightly simplify apps using 
WebSocket channels (no need to store the WebSocket object, no need to 
clean it up when it finishes), but that's a pretty minor win.  In 
DataChannels, many channels won't 'finish' while the connection is up.

I'm in favor ok keeping the "normal" GC behavior, probably with a 
trigger on refcount 0 to close the connection.

(CCing some WebSockets people...)
-- 
Randell Jesup
randell-ietf@jesup.org
Received on Thursday, 13 September 2012 06:28:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 September 2012 06:28:28 GMT