w3c / w3c/webcodecs

Reference counting and "new reference"

Open
#379 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

editorial
Dominant language
HTML
Stars
1.3k
Forks
194
Avg merge
1d 13h
Merged PRs (30d)
3

Description

I understand the desire to give implementations advice on how to best manage memory for these objects, but I don't think that should translate into normative language. Especially as that normative language is what is already the case for the web platform.

If A holds a reference to B, that's a strong reference that cannot be collected. And if C now also holds a reference, B has two things pointing to it. And cannot be collected until either those references are cleared or A and C disappear.

I would therefore suggest:

  • Turning most of the reference counting section into a note, to the extent you consider it worth keeping.

  • Remove "A media resource MUST remain alive at least as long as it continues to be referenced by a [[resource reference]]." as that is already required.

  • Change language of the form

    1. Let resource be the media resource referenced by data’s [[resource reference]].
    2. Let reference be a new reference to resource.
    3. Assign reference to [[resource reference]].

    to

    1. Set ???'s [[resource reference]] to data’s [[resource reference]].

(Currently it's not always clear what object the internal slot is from, that's the ??? above. I'd recommend spelling that out each time.)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the reference-counting section and the algorithms containing [[resource reference]] mentioned in the issue. Check which object owns each internal slot and compare the current normative requirements with the proposed note, removal, and wording changes; it is done when the affected spec text consistently names the owner and reflects the agreed reference semantics.

Written by the indexing model from the issue text.

Assessment

Tech stack
html
Domain
api, documentation
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.