Re: New proposal for fixing race conditions

Hi all,

On 23/07/2013 17:11, "Chris Wilson" <cwilso@google.com> wrote:
>This seems like an awfully big deal to me, so I have to question - what's
>the benefit?  It is
> not to my knowledge required to avoid crashes or other potential
>security issues; the only downside is if an author modifies a playing
>audio buffer, they could get differing playback results depending on
>precise timing.  That doesn't seem any different, to
> me, than what happens with small timing differences in event delivery
>today, or setting audio times that are too close to "now" - if you want
>the full power of the audio system, you have to learn how to work closely
>with the system and adapt to environments.
>  As Chris pointed out, there is some experience working with the API as
>it is today, and I haven't heard of (or personally experienced) any
>problems traced to this issue.
>[…]
>I feel designing the API around prevent race conditions everywhere is 1)
>ultimately not going to be successful anyway, and 2) is like wrapping
>everything with bubble wrap.  It will prevent some minor bruises, but it
>will also make it quite a bit more costly
> (in memory and time) to get the tasks needed done.

I'll take my co-chair hat off for a minute - just to note that the way
Chris just presented his point resonates with me. Having worked in
security (a long time ago) I do struggle a bit with the idea of fixing a
problem on principle, rather than after weighing the severity, probability
of the problem and the cost of fixing it.

To be honest, the possibility of setting a precedent or being the only API
in the whole web platform with a race condition does not worry me as much
as a discussion about fixing a risk where the group can't remotely agree
on:

* the probability (ROC's examples versus ChrisR's point that in 2 years of
early adopter usage there has been no recorded instance of the problem) of
the problem,
* the severity (opinions seem to range from "it's not a bug it's a
feature" to "serious interoperability risk") of the problem,
* the cost of fixing the problem later rather than now (hardly discussed
at all), or
* the cost of the proposed solutions (e.g "I doubt that memcpy will do
much harm" versus "quite a heavy weight on interacting with audio buffer
data").

[co-chair hat somewhat back on] Obviously, I am not saying that proponents
or opponents of any solution have been relying solely on abstract
principles in their argumentation. I do however invite everyone to
consider the criteria above rather than principles of purity if/when we
move to a vote (more on this soon).


>Olivier, to answer your question, I believe this would currently be an
>Objection.

[co-chair hat firmly back on] Noted, thanks.

Olivier



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

Received on Wednesday, 24 July 2013 11:03:01 UTC