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

On Tue, Mar 4, 2014 at 12:35 AM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:

> 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 situation here is different from Web Audio. In Web Audio we had
true races between threads. In this EME case, there is a well-defined time
at which the array contents are used --- when the task scheduled by
"Schedule a task to initialize the session, providing contentType, initData,
and the new object." runs in the HTML5 event loop. Therefore, as far as I
can tell, you don't necessarily need to specify anything here. In David's
original example, the value 9 would always be used.

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

In Web Audio we avoided requiring implementations to support copy-on-write
optimization of typed array buffers. We did this by specifying that typed
arrays passed to certain APIs are neutered --- effectively, ownership of
the buffer is transferred to the callee and it's impossible for Web content
to modify that array afterward. Applying that approach to David's example,
the assignment of 9 would fail because the array would have length 0 after
being passed to createSession.

As far as I know, nothing in the Web platform currently depends on COW
optimization of typed array buffers for efficiency. I'd like to preserve
that if possible.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w

Received on Wednesday, 5 March 2014 21:56:06 UTC