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