Re: Proposal for fixing race conditions

On Wed, Jul 17, 2013 at 11:57 AM, Jer Noble <jer.noble@apple.com> wrote:

> That is also a crucial point which I believe is getting lost in this
> conversation.  These performance concerns are only about how efficiently we
> can run legacy code while maintaining the current API.  If we're willing to
> break API backwards compatibility by making AudioBuffers immutable for
> example, and avoid using Float32Arrays anywhere except as an argument to
> the AudioBuffer constructor, then we'll avoid all of the memcpy costs in
> the normal usage of the API, except when creating an AudioBuffer.  So, it's
> not like that our two alternatives are not fixing the race conditions at
> all, or memcpy data all the time on every call into the API.
>
>
> Generally that is true, but "except when creating an AudioBuffer" is a
> very large caveat. There are some use cases (e.g., generated audio
> playback) which would hit this edge case.
>

The only way to avoid the memcpy when creating an AudioBuffer would be to
neuter the argument passed to it, but that will make the Float32Array
passed to it unusable from that point on, which may or may not be
acceptable.  We can also design an asynchronous AudioBuffer creation API so
that the memcpy can be implemented off the main thread (like how
decodeAudioData currently works.)

We need to come to terms with the fact that there is no free lunch.  We
just cannot design an API which never memcpy's anything and is free from
data race conditions.  Instead of discussing how terrible memcpy's are, we
need to discuss how we can avoid doing them in the use cases which we
expect to be common, or how to diminish their performance impact if they're
impossible to avoid.  This is where having practical performance sensitive
test cases which examines those scenarios come in handy.

--
Ehsan
<http://ehsanakhgari.org/>