- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Sun, 24 May 2015 09:41:22 -0400
- To: Peter Thatcher <pthatcher@google.com>
- CC: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <5561D502.9060906@mozilla.com>
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