Re: Proposal for fixing race conditions

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

>
> > On Jul 16, 2013, at 11:17 PM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
> >
> > It's not clear to me how this example works. If the decoder is decoding
> into a buffer that's being played at the same time, hilarity ensues. If
> it's not, we can reclaim the buffer internally as I pointed out in a
> previous message.
>
> I wasn't targeting your specific proposal in this example, but rather the
> worst case specification of "always copy". Your proposal does an admirable
> job of limiting mallocs and memcopys wherever possible, at the expense of
> implementation and spec complexity.


Maybe I'm missing something, but as far as I know, nobody has made such a
proposal, so I'm not sure why we're discussing that.

As Robert pointed out earlier in this thread, the only cases where the
current proposals suggest blind copying are AudioParam.setValueCurveAtTime
and WaveShaperNode.curve.  The basic reason is that those APIs deal with
Float32Arrays and not AudioBuffers, so neither Robert's or Jer's proposals
for AudioBuffers will directly address that, unless we're willing to break
those APIs and make them use AudioBuffers.

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.

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