- From: Sergio Garcia Murillo via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 Jan 2019 17:24:31 +0000
- To: public-webrtc-logs@w3.org
> We have the competition discussion longer than I've been participating and I doubt it's going to make much of a difference if we intentionally drop packets because the event loop queue is already overburdened. The browser will likely have different issues once it reaches that point. One thing is competition, and another one is causing unneeded retransmisión. The RTP loop is not going in the main js thread, also audio/video encoding/decoding can be done in hardware, so media can be perfectly fine even if js loop is causing cpu overuse, specially on low end devices with dedicated media chips. >.send raises an exception if one tries to send a message larger than the other peer supports. I was only referring to the receiving side (sender can be a server with proper streaming api implemented). > Can spontaneously deadlock? No. Can go OOM? Perhaps in dire circumstances. I wouldn't judge browsers killing data channels or even peer connections that go insane with memory usage as long as it's documented. Ok, so if we instead of causing a deadlock, we document that in case that the `a_wnd` is exhausted and the browser has no completed messages to deliver to the api, then it will close the datachannel/discard the current messages/close pc, would it be ok then? -- GitHub Notification of comment by murillo128 Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-458222900 using your GitHub account
Received on Monday, 28 January 2019 17:24:32 UTC