- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Thu, 13 Sep 2012 14:59:42 +0200
- To: Randell Jesup <randell-ietf@jesup.org>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>, Patrick McManus <mcmanus@ducksong.com>, Jason Duell <jduell@mozilla.com>
On 2012-09-13 08:25, Randell Jesup wrote: > 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. > Yes, the extra rules are only meaningful if no references exist > 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.) > True, a channel with pending events should not be gc'd as well. WebSockets have a similar rules for objects with pending data. > 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.) > We can't fire an event listener if the instance have been gc'd since the event needs to have a target. We would have to go with the nuke-alternative in this case. > 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. > Other networking web APIs, besides WebSockets, use this behavior as well (EventSource, XMLHttpRequest). I think it's what developers are used to and it could be confusing if a DataChannels, which are similar to WebSockets in many ways, behave differently in this regard. > 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...) Good idea. /Adam
Received on Thursday, 13 September 2012 13:00:16 UTC