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

On 5/4/15 2:31 PM, Harald Alvestrand wrote:
> On 05/04/2015 07:47 PM, Jan-Ivar Bruaroey wrote:
>> 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.
>>
>
> Does the JS programming model allow truly parallel threads?
>
> I have been told many times that the JS event loop requires that 
> things must happen as if only one piece of JS is active at any one 
> time, and that therefore most of the locks and critical section 
> mechanisms we're used to in other languages are not needed in JS.

This matches my understanding.

> (I've always taken this to mean that any effect of true parallelism 
> has to be hidden from JS, rather than imagining that it's truly 
> single-threaded.....)

You're right! Though, as I understand it, this is a matter of good spec 
design rather than some implicit guarantee or assumption (e.g. why we 
have "queue a task" everywhere).

I got confused by this line in the spec [1] which I think is wrong: "If 
the length of the operations array is exactly 1, execute the function 
from the front of the queue asynchronously."

I mistook "asynchronously" to mean "in parallel" [2]. We should strike 
that word (or accept my PR which nukes it), as the function is just 
executed. It is up to each function what to do once executed (e.g start 
stuff in a parallel thread or not).

> If this is still true, we're talking about actions being taken in the 
> next task to be taken off the main event queue, so we can still reason 
> about what happens between "now" and the end of this function.

Not necessarily. We're back to what happens inside createOffer, which 
seems under-specified, as it has no processing model.

Unless we merge my PR or explicitly "queue a task", createOffer would 
presumably read everything synchronously, which would cause trackY to 
*not* be included in the offer, i.e. it would work one way when the 
queue is empty and a different way when not (problem #1 - action at a 
distance).

>> 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.
>
> That might work - being explicit that createOffer is being done based 
> on the senders that exist at the point in the code where createOffer 
> is called.
>
> In writing the text, this will mean that createOffer gets a 
> description that says "first marshall the stuff you're going to take 
> action on, then queue a task to actually do your action".

That sounds almost right. I think it can red "run these steps in 
parallel", since if it copies what it needs then it shouldn't need to 
"queue a task".

> There's many pieces of such description in HTML5 and elsewhere, I 
> believe, so we should not be lacking in models.
>
> Just hope we can avoid inventing any new terms of art while describing 
> this :-)

I hope so as well.

.: Jan-Ivar :.