Re: New proposal for fixing race conditions

On Wed, Jul 24, 2013 at 4:11 AM, Chris Wilson <cwilso@google.com> wrote:

> AFAICT, all the proposals made so far - Jer's included - put quite a heavy
> weight on interacting with audio buffer data. For the purposes of
> synthesizing my own audio data, this will require a memcpy.
>

Not with my proposal.

Also, Jer's proposal can be modified to eliminate copies in many cases, by
introducing neutering operations (or additional APIs for constructing an
AudioBuffer from ArrayBuffers that get neutered). Jer didn't do this
himself because he's averse to using neutering, but as we have discussed I
think that position is untenable.

In mobile scenarios, and desktop scenarios with large buffers of data (i.e.
> a DAW), this will put a significantly destructive additional burden on the
> environment required to play (and likely record/process) audio.  This seems
> like an awfully big deal to me, so I have to question - what's the benefit?
>  It is not to my knowledge required to avoid crashes or other potential
> security issues;
>

*Something* must be changed to avoid security issues when an ArrayBuffer
shared with Web Audio is neutered via postMessage or some other mechanism.
Chris has proposed (informally) to fix it by adding "non-neuterable
ArrayBuffers" to the Web platform, but as we have discussed I doubt that
will be received sympathetically.

Any approach that avoids sharing ArrayBuffers with the audio thread will
avoid this neutering problem. Any such approach will also be compatible
with any future changes to ArrayBuffer (e.g. if we wanted to add resizable
ArrayBuffers to the platform).

Also, correct me if I'm mistaken, but I don't believe this is equal to
> "browser x will operate differently than browser y" - timing is everything
> in this scenario anyway, and actually even Jer's proposal could enable
> different behavior across browsers/environments, it would just be replacing
> the entire buffer instead of a portion.
>

Yes and no.

On one hand, Jer's proposal (and any other proposal that allows
modifications to an AudioBuffer that's being played) mean that depending on
buffering and other implementation details, modifications to a playing
AudioBuffer may or may not be played.

On the other hand, on some NUMA memory architectures there's no guarantee
that writes to a shared-memory buffer will become visible to another thread
*ever* in the absence of explicit synchronization. Jer's setter method at
least gives the implementation a good place to put the explicit
synchronization. (We don't use such architectures where browsers run today,
but we probably will if CPU core count keeps growing.)

I think there is a real danger that we could have author code that always
works on one implementation and never works on another implementation. Yes,
that can happen today with timing issues in other APIs --- and that's not
something we should emulate.

I feel designing the API around prevent race conditions everywhere is 1)
> ultimately not going to be successful anyway, and 2) is like wrapping
> everything with bubble wrap.  It will prevent some minor bruises, but it
> will also make it quite a bit more costly (in memory and time) to get the
> tasks needed done.
>

Preventing every kind of error that could be described as a "race
condition" is not the goal here. That makes the perfect the enemy of the
good.

An interesting exercise: assume we allow races on AudioBuffer's ArrayBuffer
contents, and figure out what the spec needs to say about what is actually
played by an AudioBufferSourceNode. I think it's going to be rather
complex. (I think this exercise will be useful because I think it will
illuminate the differences between nondeterminism due to data races and
other kinds of nondeterminism.)

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*