On 5/3/18 6:21 PM, Karl Tomlinson wrote:
I didn't understand why he was highlighting "order of object tear-down", nor why he was implying that only "VERY fine-grained" knowledge was a problem.
Alex, depending on whether he's speaking with his TAG hat or Google hat on, is either trying to figure out whether there is a problem with the spec or trying to justify Google shipping a particular behavior. I'm not quite sure which hat he's wearing here.
He does seem to have misunderstood that there is a problem to fix. But I assume the way forward here is to help the WG find a solution that works. What is the advantage of explaining the situation to Alex?
As a TAG member, he can work with the TAG to explain to the WG that their current spec is not acceptable, assuming he's convinced on that.
With his Google hat on, he can make similar arguments internally about Chrome's implementation.
So if there is in fact a problem still remaining, convincing Alex that it's there is pretty valuable. Having him convinced it doesn't exist is actively harmful as far as getting it fixed goes.
Should specifications instead just focus on observable behavior, and leave it to implementations to optimize and to reclaim resources that are no longer required?
Generally speaking, yes. That said, specifications should be really clear on which resources are no longer required, if possible.
Are you aware of any guidance I could reference, if advocating this? (The WG has been very keen to make this normative.)
If there is no difference in observable behavior, what would a normative requirement mean? And if there _is_ a difference in observable behavior, then of course the actual observable behavior that implementors need to implement needs to be specced normatively; this doesn't require saying anything about GC.
Perhaps it would be best to just have an informative section explaining design decisions made for the sake of making resource reclamation possible, such as lack of graph introspection.
This would definitely be useful.
Perhaps it would also be helpful to have some informative reminders to implementations re what GC must not affect.
Yes, that would be helpful.
If the whole normative AudioNode lifetime section were dropped then this would clearly be an implementation issue rather than a spec issue.
Assuming there is no observable behavior involved (other than memory usage), right?
The history here is:
Thank you for the summary. That was helpful. One thing I'm not 100% clear on at this point: are there spec issues that can lead to observable GC, or are we just talking about implementation bugs that make GC observable now?
-Boris _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
