On Tue, Jul 30, 2013 at 2:23 PM, Jussi Kalliokoski < jussi.kalliokoski@gmail.com> wrote: > On Tue, Jul 30, 2013 at 8:15 PM, Jer Noble <jer.noble@apple.com> wrote: > >> >> On Jul 30, 2013, at 10:04 AM, K. Gadd <kg@luminance.org> wrote: >> >> > set() isn't automatically a race because you can have it acquire a >> mutex that the mixer holds when it's using the buffer as an input or output >> for mixing. Having a mutex acquired every time you set an element of a >> typed array does not seem like something VM implementers would have been >> excited to implement. The fact that timing is important is separate from >> the fact that unsynchronized access to a buffer from multiple threads is >> risky. >> >> A mutex would be overkill here. Both the start and end points occur on >> the main thread: after calling (e.g.) AudioBufferSourceNode.start(), >> further modifications to AudioBuffer would throw. They would continue to >> throw until the ‘ended’ event fires. Doing it this way (rather than >> acquiring a mutex when the audio thread begins accessing the memory) means >> the behavior is deterministic and specifiable. >> > > This is the way I assumed it would work, and I think it's a very good > approach. > Another way to think about this is that we would "neuter" the AudioBuffer when playback on it has started, we're just not using the neutering mechanism built into typed arrays (which is what Roc's proposal does). Cheers, -- Ehsan <http://ehsanakhgari.org/>
Received on Tuesday, 30 July 2013 21:42:52 UTC