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

On Mar 3, 2014, at 15:48 , David Dorwin <ddorwin@google.com> wrote:

> Thanks for the feedback. I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=24904. Feel free to continue discussion of the EME instances in that bug. (MSE probably needs a bug as well.)
> 
> As for a consistent approach across specs, is this something the TAG should address? Should we file a more general bug somewhere?

I was thinking that this kind of consistency question might indeed be a TAG issue.  What’s the point of having highly-paid specialists if we never ask them questions? :-)

> 
> 
> On Mon, Mar 3, 2014 at 2:40 PM, Mark Watson <watsonm@netflix.com> wrote:
> 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/
> >>
> >
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Tuesday, 4 March 2014 00:14:16 UTC