W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2018

[webrtc-pc] Possibly racy replaceTrack()

From: henbos via GitHub <sysbot+gh@w3.org>
Date: Tue, 09 Jan 2018 10:24:46 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-287038256-1515493485-sysbot+gh@w3.org>
henbos has just created a new issue for https://github.com/w3c/webrtc-pc:

== Possibly racy replaceTrack() ==
Roughly speaking, replaceTrack() does this:
In parallel:
  Determine if negotiation is needed, if it is, reject promise.
  Otherwise queue a task that runs the following steps:
    Set track and resolve promise (unless pc is closed).

I think there's two issues with determining if negotiation is needed in parallel and then queuing a task to complete the operation:
1. It's possible that in-between checking that negotiation was not needed and running the task, the sender is modified such that negotiation would indeed be needed. The track is replaced even though it can't be sent seamlessly. Assuming we don't get encoding errors, how will the other endpoint react?
2. Performing the "is negotiation needed" check in parallel means it is racy, we don't know if it will occur before or after removeTrack(), for instance:
let promise = sender.replaceTrack(track);
// Will "is negotiation needed" happen before or after removeTrack()?
I can see this code snippet resolving or rejecting the `promise` depending on a race. Do we care?

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1728 using your GitHub account
Received on Tuesday, 9 January 2018 10:24:48 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:43 UTC