Re: New proposal for fixing race conditions

Just to clarify (because this discussion has been so lengthy), my understanding is this performance cost (whatever its size) is associated with *fixing* the current shared-memory model to avoid the security problems resulting from visibility of shared memory that is no-longer-owned due to neutering. It is not a side-effect of anything to do with Jer's proposed new API change. Correct?

The original non-neuterableness proposal from Chris Rogers appears to have occurred off-list AFAICT and all I find are responses to that proposal.

Sorry to be asking these questions but I've been studying the mail archives assiduously and want to make sure I am making an informed vote and participating in the discussion in an informed way. It is rather a challenge to stay on top of these issues. I appreciate everyone's help.

…Joe

On 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.
> 
> Cheers,
> Jussi
>  
> -Jer
>