Re: Vote on the data race issue and Gecko shipping timeline

On Sat, Aug 10, 2013 at 1:59 AM, Joseph Berkovitz <joe@noteflight.com>wrote:

> Also, if the shared-memory approach isn't clarified further, perhaps the
> de facto content of the option is, "the behavior in <some set of potential
> race situations> is unspecified". I don't see it as a requirement for
> *voting* that the shared-memory approach absolutely nail down how race
> conditions work (or even commit to doing so in the future). However
> attractive or unattractive, one can still vote for or against a position
> that the outcome under potential race conditions is indeterminate.
>

If we were to adopt the shared-memory approach, the spec will eventually
have to clarify what a "potential race condition is" and what
"indeterminate" means. For example, we would definitely have to have spec
text that tells authors when it's OK for well-behaved apps to modify
AudioBuffer arrays, i.e. the spec would have to define when an AudioBuffer
should be considered "in use". We would probably also want to constrain
"indeterminate behavior" somehow, and the choices are not necessarily
obvious; e.g. we might or might not want to say that when an "in use"
AudioBuffer is modified the output of currently-live AudioNodes is
undefined but the output of AudioNodes that become live later is defined.
Some of these spec clarifications might differ for AudioContext vs
OfflineAudioContext too.

One reason this matters for the vote is people have indicated complexity
for authors, implementors and the spec is an important evaluation metric.
Without a proper spec, that's hard to evaluate. I'm sure that once it's
properly defined, the "freely share memory" proposal isn't going to look as
simple as it does right now.

Another reason is that if the shared-memory approach is clarified after the
vote, some of its supporters may discover they don't like what they voted
for.

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