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