Re: Proposal for fixing race conditions

I'd like to have a chance to go through Robert's list one more time.  I
think there has been a lot of heat but little light so far, with a
considerable amount of hand waving.

Of course I think we all agree that we need to have a system which is safe
and secure.  But please apply more discretion in the discussion of these
types of issues in the future.
Additionally, it's important to keep in mind the performance hit of any
memory copies.  Performance is very very important.

That's why I favor an approach that completely avoids any memory copies
during normal use of the API.  I consider the case where an ArrayBuffer is
sent to a web worker to be a fairly uncommon use case, so I think a copy
(instead of neutering) makes a lot of sense here, and avoids some problems
which Robert has raised.


On Thu, Jun 20, 2013 at 7:32 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> We need to avoid having implementation details (e.g. whether or when data
> is copied internally) affect observable output. This can be an issue when
> JS passes an array to an API (or gets an array from an API) and later
> modifies the array. We need to specify what happens in all such cases.
>
> I believe these are the remaining issues not already addressed in the spec:
>
> 1) AudioContext.createPeriodicWave(Float32Array real, Float32Array imag)
> I propose copying the data during the createPeriodicWave call.
>

This one I think we're ok on, based on my previous answer and Robert's
reply.


>
> 2) AudioParam.setValueCurveAtTime(Float32Array values, double startTime,
> double duration)
> I propose copying the data during the setValueCurveAtTime call.
>

Copying is very inefficient, so I propose we mark this Float32Array as
"un-neuterable" and a copy will be made if it's sent to a web worker.  In
normal use cases, we can benefit for avoiding the copy.



>
> 3) WaveShaperNode.curve
> I propose copying the data when the attribute is assigned to.
>

Same answer as (2)


>
> 4) AudioBuffer.getChannelData(unsigned long channel)
>

My proposal (and I should give credit to Jer Noble for the idea) is that a
new Float32Array is returned which maps onto the same underlying data as in
the AudioBuffer.  This does not involve copying data.

Furthermore, any Float32Arrays created when a new AudioBuffer is created
are marked "un-neuterable" and in the case where they are sent to a web
worker, they will be copied.

Regards,
Chris