Re: [webrtc-pc] The threading model of webrtc-pc: When are effects of in-parallel stuff surfaced? (#2502)

> **1. webrtc-pc and JSEP have separate sets of transceivers**

I agree with this as a remedy. We must avoid updating JS observable stuff off main-thread. But it's going to widen the "tiny window", so we need to eliminate that window somehow.

> 2. The API of JSEP (its set of transceivers and which signaling state it is in) is a single-threaded toolkit

I'm not sure it matters how we characterize JSEP here, as we cannot "queue" or chain _addTrack_, because it's a synchronous method. 

What I agree with is JSEP's intent here seems to clearly be C in [my previous comment](https://github.com/w3c/webrtc-pc/issues/2502#issuecomment-606668087).

I think we need to do (1) above, and then monkey patch C in webrtc-pc. It's going to get ugly.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2502#issuecomment-606675167 using your GitHub account

Received on Tuesday, 31 March 2020 14:49:23 UTC