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: Mon, 29 Jul 2013 14:42:20 -0400
Message-ID: <CANTur_7x41pK+8WKTUkPHNAj02vmN1zLZ0o58QOiG__sgyD6Cg@mail.gmail.com>
To: Jer Noble <jer.noble@apple.com>
Cc: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, "Robert O'Callahan" <robert@ocallahan.org>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, WG <public-audio@w3.org>
On Mon, Jul 29, 2013 at 2:27 PM, Jer Noble <jer.noble@apple.com> wrote:

>
> On Jul 29, 2013, at 11:21 AM, Jussi Kalliokoski <
> jussi.kalliokoski@gmail.com> wrote:
>
> On Mon, Jul 29, 2013 at 6:52 PM, Jer Noble <jer.noble@apple.com> wrote:
>
>>
>> On Jul 25, 2013, at 5:23 PM, Robert O'Callahan <robert@ocallahan.org>
>> wrote:
>>
>> 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.
>>
>>
>> To be clear, WebKit has already fixed this issue (and so, I believe, has
>> Blink), without exposing "non-neuterable ArrayBuffers" to the web.  We did
>> introduce the concept of non-neuterable buffers internally, but only as an
>> implementation detail, and that detail is not web-exposed.
>>
>
> How is that not web-exposed when it makes some array-buffers
> non-neuterable? I think that's very observable behavior and needs to be
> specced.
>
>
> It only makes the internal AudioBuffer data structures non-neuterable.
>  All ArrayBufferViews (and their associated ArrayBuffers) returned by
> AudioBuffer.getSourceData() remain neuterable (and neutered).
>
> -Jer
>
>
Hmm, so what happens if you do this, for example:

var arr = buffer.getChannelData(0);
neuter(arr);
arr[0] = 1;

Would the third line throw?
Received on Monday, 29 July 2013 18:43:34 UTC

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