Re: New proposal for fixing race conditions

On Fri, Jul 26, 2013 at 11:18 PM, Chris Wilson <cwilso@google.com> wrote:

> On Fri, Jul 26, 2013 at 12:06 PM, Marcus Geelnard <mage@opera.com> wrote:
>
>
>> 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.
>
>

Generally I'm talking about any situation that could arise from the shared
memory solution. When I wrote this, I was thinking about data that mutates
in the main JS thread as a result of processing in the audio thread. Here's
an example of such a situation:

http://people.opera.com/mage/test/webaudio-shared-data.html

The example basically hooks an oscillator to a script processor, which
extracts a reference to an input array. Then the array is observed on the
main thread, and sure enough, the data mutates during the execution of a
single JS event.

Quite an odd use case, perhaps, but a reality nonetheless.

As you mentioned it, I did a test of the non-neutering when passing an
AudioBuffer array over to a worker, and yes, it's copied instead of
neutered in Chromium.

/Marcus