Re: Proposal for fixing race conditions

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