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

Re: New proposal for fixing race conditions

From: Ehsan Akhgari <ehsan.akhgari@gmail.com>
Date: Fri, 26 Jul 2013 15:05:46 -0400
Message-ID: <CANTur_4e_5PfVVdHAnhQLdsVPm7j4oiVgXDFw=BBCttt83nQ4Q@mail.gmail.com>
To: Chris Wilson <cwilso@google.com>
Cc: "Robert O'Callahan" <robert@ocallahan.org>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, WG <public-audio@w3.org>
On Fri, Jul 26, 2013 at 12:28 PM, Chris Wilson <cwilso@google.com> wrote:

> On Thu, Jul 25, 2013 at 5:23 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>> On Fri, Jul 26, 2013 at 6:29 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>>> The severity issue here I think is rather clear and non-controversial.
>>> For content which is affected by this, you'll get corrupted audio playback
>>> in case the AudioBuffer is modified on the main thread, or you'll get
>>> corrupted audio playback and probably the ability to read memory content
>>> that does not belong to you in the case where the ArrayBuffers are neutered
>>> by content.  Robert already wrote a very simple test case to demonstrate
>>> the first issue.  It would be very interesting to see how easily one could
>>> write a test case for the second issue, but I think it will work by
>>> basically allocating a large AudioBuffer, neuter the ArrayBuffers by
>>> sending them to a worker, connect the AudioBufferSourceNode to a
>>> ScriptProcessorNode and examine the contents of inputBuffer.
>> I already posted a testcase for the second issue. Chris has informally
>> proposed to fix it by introducing the concept of "non-neuterable
>> ArrayBuffers". I don't think that solution will get past the editors of the
>> Typed Array spec (or the TAG, it looks like), but at least we agree the
>> issue must be fixed one way or another.
> Can you point me toward that?  Sorry, this thread has grown beyond
> manageability (and yes, I've contributed to that) - but this is a critical
> point.


Received on Friday, 26 July 2013 19:06:53 UTC

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