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

Re: Proposal for fixing race conditions

From: Jer Noble <jer.noble@apple.com>
Date: Thu, 18 Jul 2013 11:48:12 -0700
Cc: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, Marcus Geelnard <mage@opera.com>, WG <public-audio@w3.org>, "robert@ocallahan.org" <robert@ocallahan.org>, "K. Gadd" <kg@luminance.org>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>
Message-id: <C0C2AF88-BB5C-4C5F-85C7-76D3C2B45816@apple.com>
To: Ehsan Akhgari <ehsan.akhgari@gmail.com>

On Jul 18, 2013, at 11:41 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com> wrote:

> The problem Jer described is a bug in JavascriptCore.  There is no reason why it should be an issue in other JS engines, and I know that it is not an issue in SpiderMonkey (not sure about v8).  I think this is a bug that JSC needs to fix anyway, since neutering is already a concept used in other parts of the web platform.

There is no "fix".  JSC can assume that the length of ArrayBuffers is immutable, and those assumptions are invalidated by neutering.  Once /any/ neutering happens, this invalidates the assumptions for every ArrayBuffer in existence, forcing JSC to do a neuter-check or a length-check for every ArrayBuffer upon access.

It may be the case that SpiderMonkey and V8 check to see if an ArrayBuffer has been neutered before each and every access into that ArrayBuffer, but that just means those engines already suffer from this neutering performance penalty.

-Jer

Received on Thursday, 18 July 2013 18:48:45 UTC

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