- 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
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?) So... 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