On Fri, Aug 2, 2013 at 5:04 AM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:
> 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.
>
Thanks for raising this point, Alex. And Jussi is right here, the current
spec is impossible to implement in a safe language such as Rust, so we
would have to use non-safe Rust code or implement it in C++ if we were to
support Web Audio in Servo.
--
Ehsan
<http://ehsanakhgari.org/>
> 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
>>>>
>>>>
>>>
>>
>