Skip to content

Conversation

@recap
Copy link
Contributor

@recap recap commented Mar 10, 2025

looking into #101 and it seems that there is a deadlock (tested on M1 chip) where the write_loop or read_loop randomly blocks indefinitely. The way the throughput is calculated is that it reports a degrading performance.
degrading performance

The actual throughput is not degrading but 0. This PR updates the code to report the throughput of every loop iteration independently.
actual iteration throughput

@recap
Copy link
Contributor Author

recap commented Mar 10, 2025

I have the impression that the deadlock is happening because the requestor and responder are sharing the same tokio runtime. When I modified the offer/answer example to simulate the data_channel_flow_control but using 2 separate processes the deadlock did not materialize.

@recap
Copy link
Contributor Author

recap commented Mar 26, 2025

@rainliu Thanks for reviewing it. Do you need more input from me before merging?

@rainliu rainliu merged commit fd88278 into webrtc-rs:master Mar 27, 2025
4 of 5 checks passed
@recap recap deleted the feature/report_actual_throughput_in_data_channel_flow_control branch May 27, 2025 09:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants