Re: New proposal for fixing race conditions

> On Jul 29, 2013, at 11:42 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com> wrote:
> 
>> 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?

Yes.

-Jer

Received on Monday, 29 July 2013 19:36:30 UTC