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

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?


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/
>> >>
>> >
>>
>
>