Using webrtc::PeerConnection on a thread with I/O disallowed?

[Lambros Lambrou]

Hi,

We are running into some DCHECKs within remoting/protocol/webrtc_transport.cc:

Check failed: !g_base_sync_primitives_disallowed.Get().Get()

The DCHECKs happen because we call into some webrtc::PeerConnection methods which appear to use synchronization primitives in //base. Details are in crbug.com/793486 .

Is it correct to use PeerConnection on the network thread?

How does Chrome manage its PeerConnection instances?

Our usage does not happen inside Chrome browser - we use this code in a separate remoting host process (Remote Access), and also in a Native Messaging host process (Remote Support). I think the blocking calls only occur during connection setup/negotiation, and I don't think there would be any "jank" in our case, as these processes don't have any direct user-facing interface.

Would it be reasonable to whitelist our class to use ScopedAllowBaseSyncPrimitives, or should we try to refactor our code to call these methods on a different thread?