- From: Mark Watson <watsonm@netflix.com>
- Date: Mon, 3 Mar 2014 14:40:54 -0800
- 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>
- Message-ID: <CAEnTvdD73qbsN-8vw5OHLztVUD_pwvtrkyfYEjCNw-Q=wR1LdQ@mail.gmail.com>
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