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

Re: New functionality in PR - priority

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Sun, 24 May 2015 09:41:22 -0400
Message-ID: <5561D502.9060906@mozilla.com>
To: Peter Thatcher <pthatcher@google.com>
CC: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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 
> <mailto: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. Whenever we "queue a task" in an 
implementation, it's to hide from JS that things are happening 
concurrently *to its execution*.

In such a model, I find talk of atomicity as a problem confounding. If 
you've ever written an API that takes a callback you know it's easy to 
lock before and after such a callback and/or treat whatever that 
callback does as an envelope that determines "this set of actions". It's 
like we've forgotten single-threading where this is unavoidably 
unproblematic. In a truly single-threaded model, you call the callback 
first and update() second. There are no concurrency problems.

Perhaps you're looking for a *transaction*? That would make a little 
more sense to me. But then can setting of priority fail? And when would 
it be critical for the setting of priority to be part of an 
all-or-nothing transaction?

.: Jan-Ivar :.
Received on Sunday, 24 May 2015 13:41:54 UTC

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