W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: TAG feedback on Web Audio

From: Chris Wilson <cwilso@google.com>
Date: Wed, 31 Jul 2013 15:04:55 -0700
Message-ID: <CAJK2wqVfMqG=0CtE7Oh1z-Pv5H0ADNH9ok-3-wWic3rcowLi7A@mail.gmail.com>
To: Ehsan Akhgari <ehsan.akhgari@gmail.com>
Cc: Noah Mendelsohn <nrm@arcanedomain.com>, Anne van Kesteren <annevk@annevk.nl>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, "robert@ocallahan.org" <robert@ocallahan.org>, Alex Russell <slightlyoff@google.com>, "public-audio@w3.org" <public-audio@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>
I'm just saying "race condition" is a general term for a situation where
output is dependent on the sequence or timing of other events.  Racing is
inherent in an async platform with entropy in it; that doesn't make it bad.
 If this is explicitly about multithreaded unsynchronized data variable
access, that should be stated.


On Wed, Jul 31, 2013 at 2:45 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> On Wed, Jul 31, 2013 at 1:43 PM, 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.
>>
>
> This problem is known as data races in the common multi-threaded
> terminology, but I'm personally not attached to that name, whatever other
> name which conveys what we mean is fine.  :-)
>
>
> --
> Ehsan
> <http://ehsanakhgari.org/>
>
>
>
>> 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 Wednesday, 31 July 2013 22:05:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC