Re: Question: how should addTrack work in relation to createOffer et. al.?

On 5/4/15 11:47 AM, Harald Alvestrand wrote:
> Because it leads to exactly the behavior you outlined in your 
> analysis: The user does a set of operations in a certain sequence; the 
> result of the operation has some of the operations the user thinks of 
> as "earlier" being affected by some of the operations the user thinks 
> of as "later".

User perception was not part of my analysis. I focused on two inherently 
non-deterministic properties of the createOffer() function (and its 
siblings):

 1. Its observable behavior varies depending on whether something is on
    the internal queue or not (action at a distance).

 2. Iff nothing is on the queue (or in absence of a queue FWIW), then a
    parallel thread will be running when the call returns, making it
    impossible to reason about the effects of even subsequent
    synchronous JS actions on things already underway.


If we were to queue always (my PR) then both problems (carefully 
narrowed in scope to sync JS actions only!) would go away.

> Furthermore, as soon as the sequence of operations gets broken up by 
> visits to the event loop, it goes back to being nondeterministic:
>
> addTrack(X); createOffer(); addTrack(Y) is deterministic (but 
> surprising).

This is the sync case, and it is *not* deterministic yet without my PR.

Now on to the trickier concern I believe you and Stefan are raising 
(which is outside the scope of my PR)...

> addTrack(X); createOffer(); 
> irrelevant-promise-returning-operation().then(s => addTrack(Y)) is 
> non-deterministic. (apologies if I miswrote the => syntax).

(Syntax LGTM!) Right, a tough question: Are asynchronous operation 
outcomes (to be) insulated from timed JS events?

The practical question may be: Can the JS app, right before calling 
addTrack(Y), determine the effect it will have? In an earlier answer, I 
found the on-queue case to be detectable, it's once the operation runs 
(its parallel thread) that things become non-deterministic.

How to close this window? Perhaps we could make the senders arguments to 
the internal operation's function? E.g.

createOffer: function() {
   return this._chain(() => internalCreateOffer(this.getSenders()));
}

That might work, and not bother anyone.

.: Jan-Ivar :.