Re: TAG feedback on Web Audio

In addition, I'd ask that you be more explicit than calling this problem
"data races", because there's clearly some explicit effect you're trying to
prevent.  Any asynchronously-programmable or event-driven system can enable
developers to introduce race conditions.


On Mon, Jul 29, 2013 at 10:09 PM, Noah Mendelsohn <nrm@arcanedomain.com>wrote:

>
>
> On 7/29/2013 7:05 PM, Anne van Kesteren wrote:
>
>> On Sat, Jul 27, 2013 at 9:22 AM, Noah Mendelsohn<nrm@arcanedomain.**com<nrm@arcanedomain.com>>
>>  wrote:
>>
>>> >Again, I have no informed opinions on the specific merits, just
>>> suggesting a
>>> >useful role the TAG might play to clarify for the many members of the
>>> >community who are less expert on this than you are. Thank you.
>>>
>>
>  I'm not sure we call out data races anywhere, it's something we just
>> don't do.
>>
>
> Well, my recollection may be faulty, but I think that one of the reasons
> the TAG took the trouble to formalize things like the architecture document
> was the belief that it's easier to ask skeptics to stick to rules that have
> been written down, and especially those that have garnered formal consensus
> through something like the Recommendation track.
>
> Whether it's worth taking a guideline on data races all the way to Rec I'm
> not sure, but it seems that it would be worth setting it down formally,
> perhaps in a TAG Finding/blog post/Recommendation or whatever will get the
> right level of discussion, consensus building, and eventually attention.
>
> Certainly, of the many things that have come up recently relating to APIs,
> this one seems deeply architectural and very much within the TAG's remit.
>
> Noah
>
>