Re: Proposal for fixing race conditions

On Tue, Jul 16, 2013 at 11:14 AM, Olivier Thereaux <
Olivier.Thereaux@bbc.co.uk> wrote:

> Hi everyone,
>
> As you may have seen, we discussed the issue of race conditions during our
> group teleconference last week. It is my understanding that similar
> opinions were voiced on the call as have been written here on the list, but
> given that only a subset of participants attended the call, I would
> encourage you to go read the detailed minutes.
>
> http://www.w3.org/2013/07/11-audio-minutes.html
>
> The breadth and incompatibility of opinions makes it hard so far to
> identify consensus.
>
>
> If I may try and paraphrase the points made by the participants of the
> teleconference, we had:
>
> * Race conditions could happen but they are unlikely, so we don't need to
> act on the issue
> * Changing the API with a memcopy solution would have unacceptable
> performance impact (moot if solution does not involve memcopy)
> * Changing the API would make it more complicated than needed
> * Changing the API would be a choice between serious performance impact or
> unnecessary breaking changes
> * It would be good to make clear that after the effect changes to
> ArrayBuffer have no defined effect, but we don't need to explicity prevent
> the race conditions
> * Fixing the race condition issue is good but the solution involving
> neutering ArrayBuffers has unacceptable performance impact
> * The possibility of race conditions goes against the goal to have one
> code with same effect across platforms, devices and implementations
>
>
> It seems that we have basically three ways forward:
>
> 1. No consensus - status quo
>
> 2. Consensus that the spec needs to be clear about the possibility of race
> conditions, but no agreement around mitigating change to the API
>
> 3. Consensus around one particular solution. There were at least two I can
> recall:
>   - The original, proposed by ROC
> http://www.w3.org/mid/CAOp6jLZ9e4crmJBxv9gZWQDWjUyO9HCjRVMzhFfDLoJDdFLj1g@mail.gmail.com
>   - An alternative, proposed by Jer
> http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0678.html
>
>
> Given the state of the discussion at the moment, it is not trivial to
> determine which of the three ways is more likely to result in consensus.
> During our call last week, I suggested that we should ask the group over at
> public-script-coord (and/or the TAG) for input. It would be fair to say
> that there wasn't overwhelming support for the idea, but given the relative
> deadlock in our current discussion, I still think it would be helpful. Any
> objection to (or, indeed, support for) the idea?
>

I believe what we really need to address first is whether or not it's OK to
keep the possibility of data race conditions in the spec.  If we all agree
that this is a problem which we need to address, I believe we will be able
to reach a decision within the group.  The way I see it, we're currently
deadlocked on an answer to the first question.

I'm personally fine with taking this to other experts such as the TAG or
public-script-coord, but I fear that doing that will delay us getting to a
resolution on this matter, which would be bad for the engines that are
trying to ship an unprefixed implementation soon (Firefox and maybe
Safari).  Also, we need to have specific criteria for a consensus.  I'm not
sure what the exact policies that would define that look like, but reading
over <http://www.w3.org/2011/audio/charter/#decisions>, it seems to me that
perhaps we should try to gather a vote inside the working group first?

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>