Re: Proposal for fixing race conditions

While on this, I'd like to raise one more point regarding fixing race conditions.

Current proposals to maintain compatibility while still ensuring race conditions
occur are definitely a direction to be pursued. However, I think it would also be
good to have a general easily understood and explained strategy which is guaranteed
to not behave in strange ways and to clearly not yield race conditions as well.
This is so that a natural path for the safe evolution of the API exists.

This general strategy (comes from part of Jer Noble's suggestion) is to make 
all shareable buffers immutable. Apart from AudioBuffers being immutable 
(Jer's proposal), one way to ensure this is to also support Blobs (or the equivalent) 
in appropriate places where the API accepts Float32Arrays or ArrayBuffers. 
Blobs are immutable and not "transferable" - i.e. they won't be neutered when 
passed to workers - and binary data can also be fetched using XMLHttpRequest 
using the 'blob' response type. Blobs also carry along a "mime type", that can tell 
what the internal format is. All this, I think, makes it a good candidate as a general 
strategy to prevent race conditions while sharing data efficiently.

There are no methods using which one can mutate a Blob, so a developer can
ignore whether any copying is going when sharing a Blob between nodes in the 
subsystem. Such Blobs will also be sharable between *different* AudioContexts - 
which is not the case with AudioBuffers?

I'm not proficient with WebIDL, but I believe "union types" might help here.

Best,
-Kumar

On 28 Jun, 2013, at 5:36 AM, Chris Rogers <crogers@google.com> wrote:

> 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
>