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

JSEP's in-parallel steps can't read webrtc-pc's set of transceivers, because that is a race. We agree.
Likewise, webrtc-pc can't read JSEP's set of transceivers, because that would also be a race. And also because this set is maintained by webrtc-pc, not by JSEP, and as such is only modified in JS tasks.

If JSEP's set of transceivers is not the same as webrtc-pc's, and webrtc-pc's is not the same as JSEP, that gives us our first premise:

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

> It says: _"The steps below describe how to determine if an existing sender can be reused."_ & describes that process entirely using the [set of transceivers](https://w3c.github.io/webrtc-pc/#transceivers-set), which is only [modified](https://w3c.github.io/webrtc-pc/#ref-for-transceivers-set-2) in SRD's queued task.

We agree. This is both explicit by the spec today and is supported by premise 1).

> But unless we fix the data race in JSEP's in parallel SRD, it may still pick it up, depending on how far along we are in that in-parallel process.

I don't think so. While we know the sets of transceivers are different, and as such it does not matter if webrtc-pc's addTrack() has modified the webrtc-pc's set of transcievers yet or not, it is a valid question to ask if the JSEP's AddTrack() method has been executed yet.

I would argue that JSEP is a single-threaded toolkit used by webrtc-pc. It might be backed up by other threads doing the work like network and media, but the APIs of JSEP: AddTrack, SetRemoteDescription, etc, are written as if they were single-threaded.

Would you accept the following premise?

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

If 2) is true we can do SetRemoteDescription and we can do AddTrack, but we cannot possibly do both at the same time. The only resonable thing to do is to queue performing AddTrack until after SRD is finished on the JSEP thread.

This gets interesting. webrtc-pc determines that a transceiver cannot be recycled because in webrtc-pc SRD has not happened yet. But JSEP, having done SRD first and AddTrack second, would necessarily conclude that there IS a transceiver to be recycled.

There are two ways to resolve the contradiction:
1. Make webrtc-pc's decision about which transceiver to recycle override JSEP's decision about which transceiver to recycle.
2. Make JSEP decide, but this would necessarily have to make the addTrack() method promise-based.

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

Received on Tuesday, 31 March 2020 09:27:05 UTC