Re: New functionality in PR - priority

On Sun, May 24, 2015 at 6:41 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

>  On 5/22/15 8:23 PM, Peter Thatcher wrote:
>
>  On Fri, May 22, 2015 at 5:18 PM, Jan-Ivar Bruaroey <jib@mozilla.com>
> wrote:
>
>>  On 5/22/15 10:02 AM, Peter Thatcher wrote:
>>
>>  Along those lines, has there been consensus on the list for having
>> RtpSender.priority as an attribute?  I would be opposed to that for the
>> same reason I was opposed to making any of the similar settings being
>> attributes, as was proposed recently.  Even if it's at the RtpSender level,
>> it should be part of RtpSender.setParameters, so that many like changes can
>> be made atomically (without relying on strange Javascript idiosyncrasies).
>>
>>
>>  What strange Javascript idiosyncrasies? That it's not multi-threaded or
>> in need of locking?
>>
>
>  ​The same ones we talked about the last time "many attributes vs. one
> set method" came up. ​  The same arguments apply here, and I'm still in
> favor of one set method.
>
>
> Those arguments didn't make any sense to me. Could you summarize the
> problem you're seeing with concurrency succinctly?
>
> Keep in mind that JavaScript is essentially a bunch of callbacks, none of
> which are allowed to take any appreciable amount of time, or indeed even
> observe the passage of time.
>

I don't understand this claim. Content JS can chew up huge amounts of time,
though of course
eventually the browser will start to complain about the thread being
stalled.

As far as observe the passage of time, consider the following code:
var d1;
var d2;

d1 = new Date();
d2 = new Date();

while (d2.getTime() == d1.getTime()){
  d2 = new Date();
}

alert("d1=" + d1.getTime() + " d2=" + d2.getTime());

Is it your claim that the loop never terminates?

-Ekr