Re: New proposal for fixing race conditions

On Wed, Jul 24, 2013 at 7:02 AM, Olivier Thereaux <
Olivier.Thereaux@bbc.co.uk> wrote:

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

I can speak for myself here, but I have little interest in talking about
this problem in principle.  I believe it's a problem with practical
consequences.


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

Fair enough, for the purpose of this email, let's grant that it's OK to
start exposing data races to the web and teach developers how they should
avoid them (by either telling them not to do "bad" things, or asking them
to start using the ended event for AudioBufferSourceNode, which seems very
similar to asking people to use synchronization semantics to avoid data
races on other platforms.


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

My experience dealing with broken web content code throughout years has
convinced me that there is so much variance in people's level of expertise
and knowledge out there in the web developers community that pretty much
anything bad can and will happen in their code, and expecting them to not
do something which seems obviously bad is often going to end up in a bad
way.  Really bad examples of this that I can think of off the top of my
head are synchronous XHR, local storage, and (perhaps worst of all) DOM
mutation events.

I respect Chris Rogers' experience with his implementation in WebKit and
the way that people have used it, but Web Audio is not as widely used as
other web platform features yet, and I have a very hard time convincing
myself that the bad coding patterns which we have seen over and over again
in pretty much all of the APIs will somehow not happen in the case of Web
Audio.


> * the severity (opinions seem to range from "it's not a bug it's a
> feature" to "serious interoperability risk") of the problem,
>

The severity issue here I think is rather clear and non-controversial.  For
content which is affected by this, you'll get corrupted audio playback in
case the AudioBuffer is modified on the main thread, or you'll get
corrupted audio playback and probably the ability to read memory content
that does not belong to you in the case where the ArrayBuffers are neutered
by content.  Robert already wrote a very simple test case to demonstrate
the first issue.  It would be very interesting to see how easily one could
write a test case for the second issue, but I think it will work by
basically allocating a large AudioBuffer, neuter the ArrayBuffers by
sending them to a worker, connect the AudioBufferSourceNode to a
ScriptProcessorNode and examine the contents of inputBuffer.


If I'm not mistaken, Chris Rogers does not argue that these problems do not
exist, he argues that they're not important enough to fix.


> * the cost of fixing the problem later rather than now (hardly discussed
> at all), or
>

That depends on the proposal that will later end up getting adopted.
Adopting something like Robert's proposal will probably not break most
content out there, but it will definitely break some (there are test cases
right now which don't work in Firefox because we neuter the ArrayBuffers).
Adopting something like Jer's proposal will mean breaking APIs in pretty
severe ways, which I believe will be extremely difficult.


> * 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").
>

I also believe that by now we have a clear idea on where each memcpy
operation will exactly happen.  I don't think we agree on the performance
implications though.


> [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).
>

Does the above help?

Thanks!
--
Ehsan
<http://ehsanakhgari.org/>


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