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

Re: Vote on the data race issue and Gecko shipping timeline

From: Ehsan Akhgari <ehsan.akhgari@gmail.com>
Date: Fri, 9 Aug 2013 15:10:25 -0400
Message-ID: <CANTur_7DrRkahjHjNDAaqPzDV6d2dnkxsaDXr+V61tEDGZ7v+g@mail.gmail.com>
To: Joseph Berkovitz <joe@noteflight.com>
Cc: Chris Lowis <chris.lowis@bbc.co.uk>, "public-audio@w3.org" <public-audio@w3.org>
On Fri, Aug 9, 2013 at 9:59 AM, Joseph Berkovitz <joe@noteflight.com> wrote:

> On Aug 9, 2013, at 5:18 AM, Chris Lowis <chris.lowis@bbc.co.uk> wrote:
>
> This is a good point. If we go to a vote it needs to be clear what people
> are voting on and what the implications will be.
>
>
> Clarity on every option would be ideal. However, we are at an impasse that
> is holding back everyone's progress, both browser implementors and
> developers.
>

Yes, unfortunately. :-(


> I appreciate the chair's efforts in trying to reach consensus and I
> understand that August is a tough time to crack the schedule whip. But at
> this point I would like to request that the chair set a firm deadline for
> finalization of the proposals, followed by a firm voting date. If one of
> the options is not clear after the finalization date, that can hardly be
> the fault of the voting process.
>

I would really prefer having fixed dates as well.


> Also, if the shared-memory approach isn't clarified further, perhaps the
> de facto content of the option is, "the behavior in <some set of potential
> race situations> is unspecified". I don't see it as a requirement for
> *voting* that the shared-memory approach absolutely nail down how race
> conditions work (or even commit to doing so in the future). However
> attractive or unattractive, one can still vote for or against a position
> that the outcome under potential race conditions is indeterminate.
>

Well, but what would the behavior being unspecified actually means?  One
could interpret that as either what WebKit/Blink and Gecko implement today,
and they're clearly not the same and not completely inter-operable.  I
think what the proponents of the "let things be" solution really want is
shared memory access between the main thread and the audio thread, and
leaving things unspecified is a little bit shying away from saying that
explicitly.  There are many reasons why shared memory access is not OK as
discussed within the past few weeks, and I would like us to have a detailed
proposal from this side too which addresses what the exact behavior needs
to be and why the trade-offs towards shared memory access are being made,
especially since this will have drastic effect on environments which do not
provide shared memory at all.

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>
Received on Friday, 9 August 2013 19:11:34 UTC

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