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

Re: Proposal for fixing race conditions

From: Chris Rogers <crogers@google.com>
Date: Wed, 17 Jul 2013 14:34:51 -0700
Message-ID: <CA+EzO0mE=ObPXG19ATrt2v7seBoRq-DHxi_w5gS2i8hxs91=6Q@mail.gmail.com>
To: Marcus Geelnard <mage@opera.com>
Cc: Ehsan Akhgari <ehsan.akhgari@gmail.com>, Jer Noble <jer.noble@apple.com>, "robert@ocallahan.org" <robert@ocallahan.org>, "K. Gadd" <kg@luminance.org>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, WG <public-audio@w3.org>
On Wed, Jul 17, 2013 at 2:28 PM, Marcus Geelnard <mage@opera.com> wrote:

> Just a few comments:
>
> 0) First, let me re-iterate that I think that it's unacceptable for us to
> move forward with a specification that allows for "shared mutable state
> without locks" (as Jens Nockert so concisely put it). I really think that
> we have to (and should be able to) find a solution to this.
>
> 1) memcpy is really, really fast on any modern CPU architecture (you'll
> find it's *the* most optimized routine, both in software and in hardware).
> Having hand optimized graphics rasterization loops in assembler for ARM
> I've learned that it's impossible to get even close to its speed even when
> only doing trivial stuff, such as adding a constant value to a buffer or so.
>

Marcus, this isn't so much an issue of how fast memcpy() is, although that
could be a concern too.  It's about the overhead of the additional memory
footprint (caused by the extra mallocs).
Received on Wednesday, 17 July 2013 21:35:19 UTC

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