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: Thu, 25 Jul 2013 00:33:19 +0200
Message-ID: <CAL8YEv5YkRf16e1MVaQDjWek_XfzB1-35tow5pXscxNYcgY4YA@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Chris Wilson <cwilso@google.com>, Ehsan Akhgari <ehsan.akhgari@gmail.com>, Jer Noble <jer.noble@apple.com>, Russell McClellan <russell@motu.com>, WG <public-audio@w3.org>
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):

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).

Received on Wednesday, 24 July 2013 22:33:46 UTC

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