- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Thu, 13 Sep 2012 02:25:47 -0400
- 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 UTC