Re: New proposal for fixing race conditions

On Tue, Jul 30, 2013 at 8:00 PM, Joseph Berkovitz <joe@noteflight.com>wrote:

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

IIUC, yes, and to clarify, I was making a point that we're going to impose
a performance penalty somewhere with all proposals, including by speccing
whatever Webkit/Blink are doing right now, so I was not arguing against
Jer's proposal to fix the problem on our side, quite the contrary. :)

Cheers,
Jussi


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