W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: New proposal for fixing race conditions

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Tue, 30 Jul 2013 21:16:36 +0300
Message-ID: <CAJhzemU5Zntd7P6dnedxBGm9hqCSHFEEohCSDi2Gnwuwd-oOSw@mail.gmail.com>
To: Joseph Berkovitz <joe@noteflight.com>
Cc: Jer Noble <jer.noble@apple.com>, Ehsan Akhgari <ehsan.akhgari@gmail.com>, "Robert O'Callahan" <robert@ocallahan.org>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, WG <public-audio@w3.org>
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. :)


> 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
Received on Tuesday, 30 July 2013 18:17:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC