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: Mark Watson <watsonm@netflix.com>
Date: Mon, 3 Mar 2014 14:40:54 -0800
Message-ID: <CAEnTvdD73qbsN-8vw5OHLztVUD_pwvtrkyfYEjCNw-Q=wR1LdQ@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.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>
It would seem to me that the only consistent approach that is guaranteed to
be suitable for the wide variety of places this problem occurs is to
require the data to be copied in the synchronous part of the function call.
Implementations can do copy-on-write optimizations if they choose.

The alternative is to say that for *all* applications it *always* makes
sense for the ArrayBuffer to remain unmodified until the asynchronous part
of the operation completes. Seems hard to make such a broad statement /
prediction.

...Mark


On Mon, Mar 3, 2014 at 2:35 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> 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:41:22 UTC

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