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

All good points... I agree on the need to nail down what is safe vs unsafe, and that there must be some definition of the scope of any indeterminacy in node space-time. 

.            .       .    .  . ...Joe

Joe Berkovitz
President
Noteflight LLC
+1 978 314 6271
www.noteflight.com
"Your music, everywhere."

On Aug 9, 2013, at 6:01 PM, "Robert O'Callahan" <robert@ocallahan.org> wrote:

> 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