Re: AudioNode GC rules

I agree that the current GC rules in the spec only help confuse people.  We
should remove them, and that should be fine with the existing
implementations since doing that will not have any observable effects on
how an implementation behaves.

Cheers,

--
Ehsan
<http://ehsanakhgari.org/>


On Wed, Mar 20, 2013 at 2:23 AM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

> On Wed, Mar 20, 2013 at 7:48 AM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> On Wed, Mar 20, 2013 at 6:21 PM, Jussi Kalliokoski <
>> jussi.kalliokoski@gmail.com> wrote:
>>
>>> Shouldn't we say that ("UAs can and should automatically prune out nodes
>>> that can't contribute to future output"), at least? To make sure nodes that
>>> can contribute don't get dropped out?
>>
>>
>> There's an implicit frame axiom in all Web specs that the UA doesn't
>> modify state unless some spec says it should. For example a
>> standards-compliant UA should not randomly replace a Web page's DOM with a
>> smiley-face image, even though no spec explicitly says it shouldn't.
>>
>> Thus, a UA that randomly removes nodes in a way affects output is just
>> buggy and non-compliant with the Web Audio spec.
>>
>
> That's true, good point.
>
>>
>> Now for example WebKit's "bug" doesn't really seem to be a bug by the
>>> spec, which has proven to be counter-intuitive for web developers that are
>>> used to creating locally scoped DOM elements (nodes) that are added
>>> (connected) to the tree (context), assigning listeners to them and assuming
>>> they stay where you put them, even though you don't have a direct reference
>>> to them.
>>
>>
>> Per my above comments, if Webkit removes a node from the graph when the
>> spec did not explicitly say it should, then it's buggy.
>>
>> Of course, unlike DOM, we don't have introspection that would let you
>>> find the node you had earlier, but I don't think that's a very good thing
>>> either.
>>
>>
>> It's actually really important that we never add that introspection. If
>> we do, then the optimizations that remove nodes that can't produce output
>> will become changes in observable behavior and we'll have to stop doing
>> them!
>>
>
> Again a very good point, and I agree. As discussed much on the list and
> calls, the best option is probably to let the javascript layer handle the
> introspection if it's necessary.
>
>
>> 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.
>>
>
> Agreed. Thanks for clearing this out for me.
>
> Cheers,
> Jussi
>
>
>> Rob
>> --
>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>> — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>> tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
>>
>
>