W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: New proposal for fixing race conditions

From: Marcus Geelnard <mage@opera.com>
Date: Sat, 27 Jul 2013 11:24:29 +0200
Message-ID: <CAL8YEv55oMMYZQ5Mtfy7vfuAxhuCEs6_a-MckYC1kUWtp_8sAw@mail.gmail.com>
To: Chris Wilson <cwilso@google.com>
Cc: Ehsan Akhgari <ehsan.akhgari@gmail.com>, "Robert O'Callahan" <robert@ocallahan.org>, Jer Noble <jer.noble@apple.com>, Russell McClellan <russell@motu.com>, WG <public-audio@w3.org>
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:


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.

Received on Saturday, 27 July 2013 09:24:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC