W3C home > Mailing lists > Public > public-html-media@w3.org > March 2014

Re: [EME] Uint8Array parameters may be modified while scheduled task is pending

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 4 Mar 2014 09:35:36 +1100
Message-ID: <CAHp8n2nQ-2iSAQEeiSn6KOZPkD6AzOBnu6xWuxQtP0MC6F8oVw@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: Henri Sivonen <hsivonen@hsivonen.fi>, David Dorwin <ddorwin@google.com>, "public-html-media@w3.org" <public-html-media@w3.org>, "Robert O'Callahan" <robert@ocallahan.org>
We also have this issue for DataCue in the HTML spec [1] with
ArrayBuffer, see https://www.w3.org/Bugs/Public/show_bug.cgi?id=24687
.
I agree we should have a consistent approach.
Would it make sense to require cloning on assignment in the IDL spec?

Silvia.

[1] http://www.w3.org/TR/html5/embedded-content-0.html#datacue

On Tue, Mar 4, 2014 at 2:39 AM, Mark Watson <watsonm@netflix.com> wrote:
> The same issue exists in WebCrypto. It would be nice to have a
> consistent approach across specifications.
>
> ...Mark
>
> Sent from my iPhone
>
>> On Mar 3, 2014, at 3:36 AM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:
>>
>>> On Sat, Feb 22, 2014 at 12:16 AM, David Dorwin <ddorwin@google.com> wrote:
>>> I believe there is a similar issue with MSE, and it was decided that such
>>> behavior is undefined.
>>
>> Seems like a bad way to deal with this.
>>
>>> Does anyone object to the behavior also being
>>> undefined for EME?
>>
>> I object to both MSE and EME introducing a race condition like that.
>> IIRC, this issue already came up with Web Audio. CCing roc for the
>> details.
>>
>> I think the method should act as if it made a copy of the data before
>> returning. In practice, it probably makes sense to have some sort of
>> copy-on-write mechanism behind the scenes to avoid copying when no one
>> is actually writing to the original buffer.
>>
>>> Do we need to explicitly document this anywhere?
>>
>> Yes!
>>
>> --
>> Henri Sivonen
>> hsivonen@hsivonen.fi
>> https://hsivonen.fi/
>>
>
Received on Monday, 3 March 2014 22:36:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:02 UTC