I'm encountering a Deadlock when using WebRTC in the 'expected' way alongside libmediasoupclient:
When using the default built-in PeerConnectionFactory this doesn't cause a deadlock, however, in that case the 'expected' correct thread from webrtc (CreateOffer expects to be called on the signaling thread) is not used, thus potentially being unsafe inside webrtc.
- Right now, one cannot satisfy the Thread-Demands from WebRTC while being deadlock free in Mediasoup. We can be deadlock free, by using another thread for all MediaSoup functions, but that violates the thread checks from webrtc. Or we use the correct threads and face the Deadlock.
- IMHO, the threading design should be reconsidered, to ensure that the expected threads are used for all the PeerConnection functions
- The use of blocking futures should be carefully reconsidered to ensure such deadlock situations don't occur, i.e. by ensuring
mediasoup::PeerConnection::CreateOffer is not called on the signaling thread, posting a task to the actual signaling thread (which has to be saved somewhere) and then waiting on the calling thread for the signaling thread to invoke the observer and thus resolving the future
- This affects all
mediasoup::PeerConnection methods that internally call any this->pc methods
I'm encountering a Deadlock when using WebRTC in the 'expected' way alongside libmediasoupclient:
PeerConnection::Optionswith a customPeerConnectionFactory(with already provided signaling/networking/worker threads)device_->Load(...)on thesignaling_thread()of thePeerConnectionFactorypc->CreateOffer()(https://github.com/versatica/libmediasoupclient/blob/v3/src/PeerConnection.cpp#L178) on the signaling thread, but then deadlock it by waiting on the future viafuture.get()2 lines downSdpOfferAnswerHandlerin webrtc (https://webrtc.googlesource.com/src/+/refs/heads/lkgr/pc/sdp_offer_answer.cc) can never invoke the observer on the signaling thread to resolve the futureWhen using the default built-in PeerConnectionFactory this doesn't cause a deadlock, however, in that case the 'expected' correct thread from webrtc (CreateOffer expects to be called on the signaling thread) is not used, thus potentially being unsafe inside webrtc.
mediasoup::PeerConnection::CreateOfferis not called on the signaling thread, posting a task to the actual signaling thread (which has to be saved somewhere) and then waiting on the calling thread for the signaling thread to invoke the observer and thus resolving the futuremediasoup::PeerConnectionmethods that internally call anythis->pcmethods