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

On 05/04/2015 10:29 PM, Jan-Ivar Bruaroey wrote:
> 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 think it is actually a hard requirement.

Otherwise, stuff as simple as

    a = new ObjectWithHandlerForAsynchronousEvent():
    a.handler = function() {}

would never function reliably. People used to other languages who come 
to Javascript always recoil in horror and ask "but where's the critical 
section?" when they see code like this.