Clarify normative aspects of AudioNode lifetime. #1161
Conversation
index.html
Outdated
| conditions do not apply, AudioNodes MAY be released by an | ||
| implementation. Additionally, implementations may apply other | ||
| methods to avoid unnecessary resource usage and unbounded memory | ||
| growth of unused/finished nodes. |
There was a problem hiding this comment.
Have we defined what "finished" means?
There was a problem hiding this comment.
I guess not. What language would you like to see here, exactly?
There was a problem hiding this comment.
Dunno. Just leave out the last sentence? Of the couple of languages that I know that have GC, GC isn't actually required as part of the language. Maybe javascript is one such language so we don't have to say anything about GCing "unused/finished" node?
|
@rtoy in #1079 (comment), I recorded the resolution that the WG reached on our Feb 2 call, which was that the issue could be resolved by making the lifetime text normative. To recap that discussion, we concluded that this is OK because the description of "active reference" for an AWN is normative, and the lifetime section piggybacks on this definition much as it does on tail-time references and other already-existing criteria for node retention. |
…methods…” which seems not to say anything useful.
index.html
Outdated
| <p> | ||
| An <a><code>AudioNode</code></a> will live as long as there are any | ||
| references to it. There are several types of references: | ||
| An <a><code>AudioNode</code></a> must remain alive as long as there |
There was a problem hiding this comment.
Actually, I think "alive" isn't well-defined here. Not exactly sure what to say here because we can certainly create an ABSN, start it, and drop the JS reference to it. The node must still play.
There was a problem hiding this comment.
But isn't this dealt with by item 2 in the list of reference types just after this paragraph, which describes a playing reference for ABSNs and other nodes that emit sound? That item has been around for a long time. It reads:
A playing reference for AudioBufferSourceNodes, MediaElementAudioSourceNodes, MediaStreamAudioSourceNodes and OscillatorNodes. These nodes maintain a playing reference to themselves while they are currently playing.
There was a problem hiding this comment.
Is this a MUST in the sense of RFC2119, or a must in english ? In any case, this behaviour is well defined on the web platform already, no need to define it here again. We can simply say that we have self-references in some cases, and everything will work out fine.
|
@padenot PTAL |
index.html
Outdated
| Lifetime | ||
| </h3> | ||
| <p> | ||
| <i>This section is informative.</i> | ||
| The following behaviors provide a normative description of the | ||
| conditions under which an AudioNode is alive, meaning that it MUST |
index.html
Outdated
| The following behaviors provide a normative description of the | ||
| conditions under which an AudioNode is alive, meaning that it MUST | ||
| be retained in the graph by an implementation. Where these | ||
| conditions do not apply, AudioNodes MAY be released by an |
There was a problem hiding this comment.
<a>AudioNode</a>s. Maybe it's better to not mention what happens if this node does not have to be retained.
index.html
Outdated
| <p> | ||
| An <a><code>AudioNode</code></a> will live as long as there are any | ||
| references to it. There are several types of references: | ||
| An <a><code>AudioNode</code></a> must remain alive as long as there |
There was a problem hiding this comment.
Is this a MUST in the sense of RFC2119, or a must in english ? In any case, this behaviour is well defined on the web platform already, no need to define it here again. We can simply say that we have self-references in some cases, and everything will work out fine.
|
@padenot I've incorporated your suggested changes; please re-review |
Fixes #1079