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

Re: [webrtc-pc] Remove stopped transceivers from getTransceivers() (#2092)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Wed, 13 Mar 2019 14:38:11 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-472447749-1552487692-sysbot+gh@w3.org>
I said yesterday in review I was having [doubts about this](https://github.com/w3c/webrtc-pc/pull/2102#discussion_r264942039). I've slept on it, and I see a problem: stats.

Stats closely [model internal object lifetimes](http://w3c.github.io/webrtc-pc/#introduction-0), so this isn't just for people who care about stats. Today, our model is that the majority of [monitored objects](http://w3c.github.io/webrtc-pc/#dfn-monitored-object) live for the lifetime of the peer connection, beyond `pc.close()` so apps can query what happened posthumously. Only objects actively *replaced*—TrackAttachmentStats by *replaceTrack*, and CandidateStats by *iceRestart*—get removed and fired in [statsended](http://w3c.github.io/webrtc-pc/#event-statsended), to curtail bloat over time (sound familiar?)


Would related sender, receiver, rtp and candidate stats disappear from `pc.getStats()` on *stop()* now? On SRD(offer) with port=0? That might be hard to foresee. On *close()*? That might fire events after *close()*, something we've avoided thus far. What if I keep a reference to a *sender* and call `sender.getStats()` on it? Does it succeed?

In short, the lifetime question is harder than removing stopped transceiver from *getTransceivers()*. We have to specify when related objects become garbage collectable, in a way that doesn't let JS detect garbage collection.

If we *don't* remove the stats, we arguably haven't fully solved the transceiver bloat problem.

The silver lining here is that stats has already solved this once, just not this way.

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2092#issuecomment-472447749 using your GitHub account
Received on Wednesday, 13 March 2019 14:38:13 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:46 UTC