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

As I cover in https://github.com/w3c/webrtc-pc/issues/2476, there are **_two_** places we special-case addTrack to _minimize # of transceivers_:
 1. In parallel SRD ([JSEP section 5.10](https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.10)): *"If ... there are RtpTransceivers ...  added ... by addTrack and are not associated ... and are not stopped, find the first ... Associate the found ... with the m= section ..."*
 2. In addTrack itself.

The first covers covers `pc.addTrack(track); pc.setRemoteDescription(offer)`
The second covers covers `await pc.setRemoteDescription(offer); pc.addTrack(track)`
So what covers `pc.setRemoteDescription(offer); pc.addTrack(track)`? TL;DR: neither I think.

The answer depends on the answer to **_two_** questions:
 1. Does JSEP's in parallel SRD read webrtc-pc's [set of transceivers](https://w3c.github.io/webrtc-pc/#transceivers-set)? That'd be a data race!
 2. Which addTrack algorithm are we running?

The answer to the first one is unclear. JSEP (oblivious to threads) is run in parallel by webrtc-pc, so this is a bug in webrtc-pc I claim.

The answer to the second one I think is covered:

> JSEP has this to say about addTrack:

That's a _concept method_ under [section 4](https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24#section-4) which states: *"The actual API exposed in the W3C API may have somewhat different syntax, but SHOULD map easily to these concepts."*

Thus webrtc-pc's [addTrack](https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-addtrack) is the algorithm that counts. 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.

So the answer is:

> if I do setRemoteDescription(); addTrack();, has SRD happened when addTrack happens or not?

SRD says _"In parallel, start the process"_, so the JSEP process may have _started_, however, that does not matter to addTrack, which only looks at 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 (which hasn't happened yet).

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. 🤢

Ironically, as I mention at the bottom of https://github.com/w3c/webrtc-pc/issues/2476, if we fix the data race, then we have a tiny window where addTrack will not associate with available transceivers. Since it would have associated itself both a few milliseconds earlier _**and**_ a few milliseconds later, that seems dead wrong.

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

Received on Monday, 30 March 2020 21:39:34 UTC