This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22432 - Allow SourceBuffer.appendBuffer to take ownership of the ArrayBuffer
Summary: Allow SourceBuffer.appendBuffer to take ownership of the ArrayBuffer
Status: RESOLVED INVALID
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: LC
Assignee: Aaron Colwell
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-24 02:27 UTC by Matthew Gregan [:kinetik]
Modified: 2013-10-11 22:33 UTC (History)
4 users (show)

See Also:


Attachments

Description Matthew Gregan [:kinetik] 2013-06-24 02:27:58 UTC
Require the "data" ArrayBuffer to be neutered during the append to allow the implementation for avoid copying the data internally and prevent races where script modifies the ArrayBuffer while it's being used internally.

Suggestion: add wording similar to that added to Web Audio's decodeAudioBuffer method: https://dvcs.w3.org/hg/audio/rev/ef43ae5230bf
Comment 1 Aaron Colwell 2013-10-04 21:08:44 UTC
Aside from WebAudio there doesn't appear to be any other precedent for "unneutering" a buffer. I talked to Kenneth Russell, one of the Typed Array spec editors, last week about this request and he did not seem very supportive of adding the "unneutering" concept. I'm happy to add text to the MSE spec explicitly pointing out that modifying the buffer while an appendBuffer() operation is pending will lead to undefined behavior. I don't think we should "neuter" and then "unneuter" during the append though since this would make all ArrayBufferViews unavailable for reading during the append.

Here is the link to the brief discussion we had on the MediaTF telecon call two weeks ago. (http://www.w3.org/2013/09/24-html-media-minutes.html#item06)

FWIW it doesn't appear like Microsoft is going to modify their implementation and at this point I don't see a large enough benefit to modify the Chromium implementation. Also Chromium doesn't currently have the ability to "unneuter" ArrayBuffers so it is unlikely that there is interop on this point even in the WebAudio case.
Comment 2 Matthew Gregan [:kinetik] 2013-10-08 10:22:03 UTC
My original comment was incorrect: there's no possible race because "data" is copied to the internal input buffer synchronously at step 3 of appendBuffer before appendBuffer reaches the asynchronous step 6, so there's no opportunity for the ArrayBuffer to mutate in parallel.

I'm happy for this to be closed as invalid.  Sorry for wasting your time!