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

Re: Proposal for fixing race conditions

From: Marcus Geelnard <mage@opera.com>
Date: Fri, 05 Jul 2013 13:01:53 +0200
Message-ID: <51D6A7A1.7090607@opera.com>
To: Chris Rogers <crogers@google.com>
CC: Robert O'Callahan <robert@ocallahan.org>, Joseph Berkovitz <joe@noteflight.com>, "public-audio@w3.org" <public-audio@w3.org>, Dave Herman <dherman@ccs.neu.edu>, "Mark S. Miller" <erights@google.com>
Just for reference, I created a small test application that behaves 
differently in Chromium and in Firefox:

http://people.opera.com/mage/test/racyaudiobuffers.html

The test app will behave oddly if the buffer data is shared between the 
audio thread and the JS context, which it is in Chromium. In this case, 
I tried to mimic the result of a "programming error" that makes the 
audio buffer array be unintentionally re-used in another place (could be 
done intentionally too, of course).

I know that this particular application is a bit unrealistic, but 
nevertheless it shows one important thing: Something that seems to work 
as expected in one browser (in this case Firefox) seems to be completely 
broken in another browser (in this case Chromium). You could also come 
up with examples that show the opposite behavior ("works" in Chromium 
but not in Firefox).

Now, regardless if we could live with a racy API or not (I strongly 
object to it), we still have the issue that the spec is not at all clear 
on how to treat arrays that have been passed to the API (as a Web 
developer I would expect them to be copied, e.g. in the same way as 
WebGL texImage2D). I really think that we need to specify this!

...and, if we go down the road of specifying racy behavior, I'm pretty 
sure that we'll make life a lot harder not only for Web developers but 
also for implementors wishing to utilize certain optimization techniques 
etc.

/Marcus

-- 
Marcus Geelnard
Technical Lead, Mobile Infrastructure
Opera Software
Received on Friday, 5 July 2013 11:03:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:10 UTC