Re: New proposal for fixing race conditions

On Tue, Jul 30, 2013 at 12:05 PM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

> On Tue, Jul 30, 2013 at 6:52 PM, Jer Noble <jer.noble@apple.com> wrote:
>
>>
>> On Jul 30, 2013, at 8:47 AM, Jussi Kalliokoski <
>> jussi.kalliokoski@gmail.com> wrote:
>>
>> Does this impose a performance cost on Float32Array access, BTW? I tried
>> figuring it out on my own but I've been following leads in the WebKit
>> source for a while and haven't found the code that does this.
>>
>>
>> We re-used the high-order bit in ArrayBufferView's offset to track
>> non-neuterableness.  So yes, in that offset calculations now need to mask
>> off that bit, but the cost is negligable.
>>
>> See:
>> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/ArrayBufferView.h#L134
>> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/ArrayBuffer.cpp#L36
>>
>
> Thanks! So, correct me if I'm wrong, but we're discussing imposing a
> performance cost (arguably negligible) to Typed Arrays use to avoid
> imposing a performance cost (arguably negligible) on the Web Audio API. To
> be honest, (probably unsurprisingly) I'd rather we take risks like this in
> our own API instead of on an API that's the foundation of high performance
> JS. We can add more surface to our API to make it faster if need be, but if
> we impose performance costs to the basic use of Typed Arrays, that's
> irreversible and damages the whole platform.
>

These are all WebKit (and maybe even WebKit + JSC) implementation details.
And the reason why we have two proposals to fix the shared-memory problem
is the bug that degrades the performance of WebKit + JSC when any neutering
happens.

When discussing how to fix the shared memory problem, we have either Roc's
proposal on the table which doesn't change the API surface but uses
neutering to prevent concurrent accesses to the same buffer, or Jer's
proposal which breaks the API surface and does not use neutering in order
to work around the WebKit + JSC bug.  I personally think that Jer's
solution is a cleaner API, but we have decided to not fix other problems in
the API in order to maintain backwards compatibility, and I would like to
urge everybody to keep the trade-offs in mind when casting their vote.

Cheers,
Ehsan