W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2015

Re: RtpSender.getParameters and RtpSender.setParameters vs. RtpSender.param1, RtpSender.param2, ...

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Mon, 08 Jun 2015 21:24:01 -0400
Message-ID: <55764031.1020301@mozilla.com>
To: Peter Thatcher <pthatcher@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 6/8/15 7:01 PM, Peter Thatcher wrote:
> ... setting them individually just doesn't make sense because the time 
> between setting them would cause the RtpSender to be in an invalid, 
> broken, or awkward state.

Sorry to disagree, but the "time between setting them" will /*not*/ do that.

It isn't possible, because RtpSender is *not allowed* to observably 
progress in that time, /because JS is a single-threaded model/.

Like it or not, this is why we queue a task for everything: to keep JS 
in the dark about anything happening in parallel to its execution. 
RtpSender is not above this law, and must queue a task before altering 
any of its properties in response to time.

Therefore, from the viewpoint of JS, RtpSender *cannot *get into an 
invalid, broken or awkward state simply by busy-waiting for it.

This:

     var state = RtpSender.someLiveState;
     while (RtpSender.someLiveState == state) {}

will never complete. I showed this earlier. [1]

.: Jan-Ivar :.

[1] https://lists.w3.org/Archives/Public/public-webrtc/2015May/0143.html
Received on Tuesday, 9 June 2015 01:24:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:44 UTC