W3C home > Mailing lists > Public > public-webrtc@w3.org > March 2014

Re: Improvements suggestion for DataChannels

From: <piranna@gmail.com>
Date: Tue, 4 Mar 2014 10:09:27 +0100
Message-ID: <CAKfGGh0NPTmQUg7XBYizEig3sAZD=DbKyrpM_=Z2EHxkPi4MHQ@mail.gmail.com>
To: Adam Bergkvist <adam.bergkvist@ericsson.com>
Cc: Randell Jesup <randell-ietf@jesup.org>, public-webrtc <public-webrtc@w3.org>
I think is implicit the DataChannel should be removed from the
PeerConnection list inconditionally when it gets closed, so the list is
only of currently active, open DataChannel objects. Later, on a side note,
if someone get a reference to a DataChannel object both from calling
createDataChannel() or from the list, it will be GC when it gets closed and
all references disappear... At least it's the most logical behaviour (and
the one I was proposing, sorry if there was some misunderstands).

Send from my Samsung Galaxy Note II
El 04/03/2014 09:58, "Adam Bergkvist" <adam.bergkvist@ericsson.com>
escribió:

> On 2014-03-03 15:15, Randell Jesup wrote:
>
>> On 3/3/2014 8:06 AM, Martin Thomson wrote:
>>
>>> On 3 March 2014 04:18, Adam Bergkvist <adam.bergkvist@ericsson.com>
>>> wrote:
>>>
>>>> I still think that's strange API behavior.
>>>>
>>> I don't see any strangeness here.  If I have a reference, then the
>>> object is not garbage collected.  If not, then not.
>>>
>>>
>> Agree with Martin.  It seems totally normal - things stay alive
>> (accessible) so long as they're referenced.  Telling it to close()
>> disconnects it, but the object exists so long as the reference exists.
>>
>
> I agree that what you describe is totally normal. The thing I was
> referring to was the conditional side effect of close(). That the channel
> should be removed from the PeerConnection's channel list if it was never
> accessed via that list, otherwise not. That may have been a
> misunderstanding from my side btw.
>
> /Adam
>
>
>
>
Received on Tuesday, 4 March 2014 09:09:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:38 UTC