On Fri, Aug 2, 2013 at 3:42 AM, Alex Russell <slightlyoff@google.com> wrote: > Let me be clearer, then: the issue is that it introduces effects to JS > that can't be described *in terms of JS*. It violates the > run-to-completion model of the language without appealing to the turn-based > concurrency model we use everywhere else in the platform. > That's a very good point, and actually not only does the current design prevent implementation in JS, but also other "safe" languages, such as Rust (AFAIK), that don't have the concept of shared memory. Cheers, Jussi > > On Wed, Jul 31, 2013 at 10:43 AM, Chris Wilson <cwilso@google.com> wrote: > >> 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 >>> >>> >> >
Received on Friday, 2 August 2013 09:04:48 UTC