On Mon, Jul 29, 2013 at 8: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 > > Not sure what that means. I did an experiment in Chromium (i.e. Blink) where I took the array returned by AudioBuffer.getChannelData() and passed it on to a worker using postMesage(). Even if the AudioBuffer was updated, the worker couldn't observe it, so I assume that the array wasn't neutered but in fact copied, but I could be wrong. /Marcus
Received on Monday, 29 July 2013 19:15:16 UTC