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

Re: Proposal for fixing race conditions

From: Marcus Geelnard <mage@opera.com>
Date: Thu, 18 Jul 2013 22:02:55 +0200
Message-ID: <CAL8YEv6Nvcf4XVpP9qmEa5cZSXRPLf-0vHaNQbxVup0rBtYvsg@mail.gmail.com>
To: Ehsan Akhgari <ehsan.akhgari@gmail.com>
Cc: Jer Noble <jer.noble@apple.com>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, WG <public-audio@w3.org>, "robert@ocallahan.org" <robert@ocallahan.org>, "K. Gadd" <kg@luminance.org>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>
...I think that we still have not come any closer to a clear answer to the
question: Why should we not try to fix the data races?

There has been some discussions as to why it's [allegedly] OK to ignore the
issues of data races, but that is a completely different question that we
could pursue once we know the actual down-sides to fixing the data races.

/Marcus




On Thu, Jul 18, 2013 at 9:11 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> On Thu, Jul 18, 2013 at 3:05 PM, Jer Noble <jer.noble@apple.com> wrote:
>
>>
>>
>> On Jul 18, 2013, at 12:03 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>
>> wrote:
>>
>> Hmm, the original ArrayBuffer will get GCed if the content code is not
>> holding on to it, right?  And if they are, that is memory that the content
>> is keeping alive.  Surely we're not trying to solve the problem of making
>> it impossible for content to write code which results in an OOM, etc.,
>> right?  Or am I missing something?
>>
>>
>> At some future date, yes.  In the current WebKit implementation, you will
>> see a severe "sawtooth" memory useage.  Doubling the live buffer size will
>> make those "teeth" taller between GCs.
>>
>
> OK, point taken.  But still I do not think that the intricacies of one
> engine's implementation should stop us from fixing spec level issues in a
> sane way, unless those problems are impossible to fix (in which case they
> will probably be a problem in all of the engines.)  To give you a concrete
> example, the rules for managing AudioNode's memory were extremely tricky to
> implement correctly in Gecko, given that they are vastly different than
> most other objects exposed to the Web platform, but for the purposes of Web
> Audio, the behavior of create nodes, set up graphs, and then let the UA
> figure out when the memory for the AudioNode can be reclaimed made sense
> from an API standpoint, and we went through all the trouble to implement it
> properly.
>
> Cheers,
> --
> Ehsan
> <http://ehsanakhgari.org/>
>
Received on Thursday, 18 July 2013 20:03:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:10 UTC