Re: DataChannels API

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