Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clarify normative aspects of AudioNode lifetime. #1161

Merged
merged 3 commits into from Mar 30, 2017
Merged

Clarify normative aspects of AudioNode lifetime. #1161

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
c63a89e
Clarify normative aspects of AudioNode lifetime.
joeberkovitz Mar 3, 2017
da51af0
Remove sentence about “Additionally, implementations may apply other …
joeberkovitz Mar 7, 2017
2859924
Incorporate @padenot feedback
joeberkovitz Mar 27, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
20 changes: 10 additions & 10 deletions index.html
View file
Open in desktop
Expand Up @@ -3088,21 +3088,21 @@ <h2>
</dl>
</section>
<section>
<h3 id="lifetime-AudioNode" class="informative">
<h3 id="lifetime-AudioNode">
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<a>AudioNode</a>

be retained in the graph by an implementation. Where these
conditions do not apply, AudioNodes MAY be released by an
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<a>AudioNode</a>s. Maybe it's better to not mention what happens if this node does not have to be retained.

implementation. Additionally, implementations may apply other
methods to avoid unnecessary resource usage and unbounded memory
growth of unused/finished nodes.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have we defined what "finished" means?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess not. What language would you like to see here, exactly?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

</p>
<p>
An implementation may choose any method to avoid unnecessary
resource usage and unbounded memory growth of unused/finished
nodes. The following is a description to help guide the general
expectation of how node lifetime would be managed.
</p>
<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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

are any references to it. There are several types of references:
</p>
<ol>
<li>A <em>normal</em> JavaScript reference obeying normal garbage
Expand Down