Implement outgoing_queues_empty for PeerConnection#91
Conversation
to provide a signal for when it's safe to tear down an event loop driving the connection after sending messages over a data channel
…t quite as noisy as initially thought
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #91 +/- ##
=======================================
Coverage 71.23% 71.23%
=======================================
Files 442 442
Lines 67356 67430 +74
=======================================
+ Hits 47979 48035 +56
- Misses 19377 19395 +18 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
I don't think adding pub fn outgoing_queues_empty in RTCPeerConnection is a good way. It is not WebRTC spec compatible.
Please consider how to implement bufferedAmount API for RTCDataChannel:
https://www.w3.org/TR/webrtc/#dom-datachannel-bufferedamount, which is currently missing and need to be implemented in some way.
|
Ok, thanks for the feedback. Managing buffer amounts is far more complicated than I need right now, and I'm out of time to spend on this. These changes as-is work well for me right now, so I'm just going to maintain them as a patch. |
To provide a signal for when it's safe to tear down the event loop driving the connection after sending messages over a data channel.
This is another attempt at fixing the issue originally behind #63 that works by adding a new
WriteQueueQuiescencetrait providing ais_write_queue_emptyfunction for all stages in the peer connection pipeline. If all stages report empty, then it should be safe for the caller of the peer connection to tear down the event loop.This was a bit tricky to implement because the ICE layer generates a ton of STUN messages that generate a lot of false positive signals. Also, hopefully I actually found all the internal queues where messages can hide.
And the interceptor layer needed special attention because it looks like it's based on a proc macro system. These changes affect the external API requirements for custom interceptors as well.
Let me know what you think.
Thanks,
Jeff