- From: Eric Rescorla <ekr@rtfm.com>
- Date: Mon, 8 Jun 2015 19:13:58 -0700
- To: Jan-Ivar Bruaroey <jib@mozilla.com>
- Cc: Peter Thatcher <pthatcher@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Received on Tuesday, 9 June 2015 02:15:15 UTC
On Mon, Jun 8, 2015 at 6:24 PM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote: > 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. > But we've already established that this isn't true with respect to time, so it's not clear to me that this is in fact an invariant. Can you please point to a specification requirement (i.e. not an experiment) that supports your argument that changes to RtpSender cannot have observable side effects before we return to a JS stable state? -Ekr
Received on Tuesday, 9 June 2015 02:15:15 UTC