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

Re: [Bug 25724] New: Allow garbage collection of closed PeerConnections

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 16 May 2014 09:24:12 +0200
Message-ID: <5375BD1C.9090409@alvestrand.no>
To: public-webrtc@w3.org
On 05/15/2014 10:11 PM, Jan-Ivar Bruaroey wrote:
> On 5/15/14 6:21 AM, bugzilla@jessica.w3.org wrote:
>> At the moment, the webrtc specification says:
>>
>> 4.3.3 Garbage collection
>>
>> A Window object has a strong reference to any RTCPeerConnection 
>> objects created
>> from the constructor whose global object is that Window object.
>>
>> In other words, RTCPeerConnections can't be garbage collected.
>>
>> In certain applications, where a lot of connections are created, used 
>> and
>> closed, this is a Bad Thing, since you can't get rid of old, closed
>> PeerConnections, and you can't reuse them either (there's no return 
>> from the
>> "closed" state).
>>
>> Proposal 1: Replace the text with:
>>
>> A Window object has a strong reference to any RTCPeerConnection 
>> objects created
>> from the constructor whose global object is that Window object, and 
>> whose
>> RTCSignalingState is not "closed".
>
> How about:
>
> A Window object has a weak reference to RTCPeerConnection objects created
> from the constructor whose global object is that Window object, and whose
> RTCSignalingState is not "closed".
>
>
> That's effectively what Firefox has, e.g. PCs may be garbage collected 
> if the JS drops all references to them.

I don't understand weak references much, but my understanding is that it 
doesn't influence garbage collection; if it's a weak reference, and 
can't be retrieved from the Window object, does it have any effect?

I think the case of having MediaStreams that continue to run despite all 
references to the PC that Stefan mentioned is important; that's covered 
if we consider the <video> element to have a reference to the 
MediaStreamTrack that has a reference to the PeerConnection as long as 
the track's not "ended".

Once a PeerConnection has close() called, all tracks sourced by it 
should end. We'd better write that down somewhere too; it's not in the 
close() description now.
Received on Friday, 16 May 2014 07:24:41 UTC

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