Re: AudioNode GC rules

> If we take all GC language out of the spec, then ScriptProcessorNodes which have event listeners attached and which are directly or indirectly connected to the destination will have to stay alive as long as they're connected. I think that's fine.

That would be fine I think .. and the "stability" expectation is an
excellent point.

I'd earlier argued for script nodes also getting the "dynamic
lifetime" behaviour as in the current spec. Though I now see the merit
in thinking of DL as a user agent optimization that isn't detailed in
the spec, I still have a few concerns.

For code like the granular synthesis example which creates tens of
nodes or perhaps hundreds of nodes every second, I would expect the
performance of the code to be determined by how early the nodes are
released. If it is purely left to the GC to do this, I'm not sure the
example would be viable with most JS engines. Would it be worth making
implementation suggestions that would make this case performant
without having to talk about GC and references?

For an analogy, this case seems similar to whether a language spec
should mandate tail call elimination. On one hand it is only an
optimization. On the other its guaranteed presence leads devs to write
very different code - perhaps using a lot of (mutual) recursion that
would in a moment bomb an implementation that didn't support TCO.
Python went the "nope" route and Scheme went the "yep" route. Both
have their fans.

-Kumar

On 20-Mar-2013, at 11:18 AM, Robert O'Callahan <robert@ocallahan.org> wrote:

> If we take all GC language out of the spec, then ScriptProcessorNodes which have event listeners attached and which are directly or indirectly connected to the destination will have to stay alive as long as they're connected. I think that's fine.

Received on Thursday, 21 March 2013 02:50:07 UTC