Re: New proposal for fixing race conditions

On Fri, Jul 26, 2013 at 12:06 PM, Marcus Geelnard <mage@opera.com> wrote:

> I guess this is what is dividing the group into two camps right now.
>>> Personally, I'd much rather go with the potential memory increase than
>>> breaking typed arrays (i.e. I'm in the "let's keep the Web webby" camp).
>>>
>>
>> Please be more concrete in the low-level principles being violated,
>> because of course no one would vote against "keeping the Web webby".  But I
>> could also say protecting developers from having to deal with low-level
>> memory issues is what makes the Web "webby".
>>
>
> Yes, the current model of "the Web" (there's probably a better term) is
> just that: protecting developers from having to deal with low-lever memory
> handling. The first part of it is that JavaScipt is a garbage collected
> language. The other part is that there is no way whatsoever to share data
> between threads in an uncontrolled manner.
>
> Until we had Web Workers, there was only a single thread (the main
> thread), and you were guaranteed that no data would change during one JS
> event (which is why, for instance, JS events are uninterruptible). When
> Workers entered the scene, the solution to information exchange was message
> passing (using cloning, and later neutering), again meaning no shared data
> between threads, and a preserved execution model.
>
> The current suggestion for introducing shared memory between threads (even
> if it's "just" between the main JS thread and the audio thread(s)), will
> shake that very foundation of the JS execution environment. From the Web
> Audio API point of view, it might seem like a minor problem, but I fear
> that others will not see it that way.
>

I still don't see that sharing memory between the main JS thread and the
audio thread shakes the very foundation of the JS execution environment.


> There are at least two important sides to this:
>
> 1) Since the rules of non-volatility no longer would apply to typed
> arrays, there may be consequences outside of the Web Audio world - and
> honestly, we can't deal with those issues ourselves but need to involve
> external interests. For instance, I know that things such as eval() and
> setters/getters affect the every day work of ECMAScript engine developers -
> why wouldn't volatile typed arrays? Also, I fear that some other specs
> would no longer be correct, and may have to be re-written. We can't naively
> assume that volatile arrays will not affect any part of the Web platform
> other than the Web Audio .
>
> 2) Once the first sanctioned instance of volatile typed arrays hits the
> Web, this will significantly lower the barrier for other APIs to consider
> it as a valid solution ("because the Web Audio API could do it, we can
> too"), and I'm pretty sure that would be A Bad Thing (TM).
>

I can't tell if you're referring to the non-neutering of ArrayBuffers WRT
the audio thread when passed to a worker, or the main thread and the audio
thread.  The latter of those is certainly a special case, as your own
imperative processing cannot happen on that thread.


> My fears may be exaggerated, but my point is that it's pointless to debate
> further within this group whether it's OK or not to have data races - we
> need external assistance to move forward (such as involving TAG, as has
> just been done).
>

I'm no longer sure we should be referring to this as a "data race" -
because race hazards will exist in any asynchronous environment.  The issue
at hand is, if I understand it correctly, implicit shared memory between
the UI thread and the audio thread.