Re: New proposal for fixing race conditions

Here's a suggestion that I haven't seen on the list. It may be dismissible on its face by those who know more about browser internals, but I believe in the power of silly ideas to stimulate discussion. At worst, they are just silly.

What if we detected potentially racy modifications to audio buffer data after the fact, by examining some sort of quickly calculated digest of the buffer (or of relevant blocks of it) in the audio thread and seeing if the digest changes between buffer accesses? If it changes, then the bad behavior could be flagged via an exception or other notification that would deter developers from going live with such applications. This would seem to avoid copying overhead and would not change the API.

.            .       .    .  . ...Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"

On Jul 24, 2013, at 6:33 PM, Marcus Geelnard <mage@opera.com> wrote:

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