Re: New proposal for fixing race conditions

On Wed, Jul 24, 2013 at 1:10 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

>
> An interesting exercise: assume we allow races on AudioBuffer's
> ArrayBuffer contents, and figure out what the spec needs to say about what
> is actually played by an AudioBufferSourceNode. I think it's going to be
> rather complex. (I think this exercise will be useful because I think it
> will illuminate the differences between nondeterminism due to data races
> and other kinds of nondeterminism.)
>

I agree. The specification is very unclear on what behavior one should
expect from an implementation when it comes to accessing
(observing/modifying) shared buffer data.

On a related note, I did another simple test app (for testing some aspects
of shared buffers):
http://people.opera.com/mage/test/webaudio-mutable-buffers.html

The demo itself isn't that interesting, but if you have a look at the code
you'll find some fairly odd and implementation-dependent solutions that I
think are not *that* far fetched (if the API's in the wild, someone will
come up with similar solutions sooner or later).

What I find especially interesting here (except that you can modify the
AudioBuffer while it's playing) is that I could get the demo working (in
Chromium) by caching the double-buffered input/output arrays in the
ScriptProcessorNode.onaudioprocess event. Sure, you *shouldn't* be coding
this way, but a mad optimizer might tend to try things like this. In
particular, this specific solution is *extremely* implementation dependent,
and will very likely fail on another implementation (even if it doesn't use
neutering or any other "tricks").

My point is:

1) *If* we're going to keep the racy buffers, the expected behavior *must*
be specified in detail. Otherwise it will be impossible to get
interoperability between different implementations.

2) It would most likely be *much* simpler to change the interfaces so that
they are well defined by design (here I think Jer's proposal is much more
well defined).

/Marcus