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

Re: Races - how bad?

From: Robert O'Callahan <robert@ocallahan.org>
Date: Fri, 2 Aug 2013 00:21:25 +1200
Message-ID: <CAOp6jLY+g6KK2wfnS0DPDFpk9X4Hj6Mau+=AkTU9Og7LAT2nug@mail.gmail.com>
To: Joe Berkovitz <joe@noteflight.com>
Cc: Srikumar Karaikudi Subramanian <srikumarks@gmail.com>, Jer Noble <jer.noble@apple.com>, Ehsan Akhgari <ehsan.akhgari@gmail.com>, "public-audio@w3.org" <public-audio@w3.org>
 On Thu, Aug 1, 2013 at 11:53 PM, Joe Berkovitz <joe@noteflight.com> wrote:

> But perhaps disconnect() on a live node already has some implicit
> nondeterminism. Which for some will raise the question: why is that degree
> of nondeterminism not considered a "race"?
>

Exactly when and how Web Audio graph changes take effect is an open issue.
http://lists.w3.org/Archives/Public/public-audio/2012AprJun/0453.html
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17327

In Gecko we do our best to minimize problems here by batching all changes
to the Web Audio graph between main-thread stable states and applying them
to the audio thread atomically. For example, if node1 is connected to
node2, and code does "node1.disconnect(); node1.connect(node2);" this is
guaranteed to have no audible effect. I think the spec should require this,
but it doesn't really impact the design of existing APIs so it's lower on
my priority list than other issues.

Obviously, even with those restrictions it's still necessarily
nondeterministic when each batch of operations is applied relative to the
progress of the audio thread. There's really no way around that; it's a
minimum amount of nondeterminism that we just have to live with.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*
Received on Thursday, 1 August 2013 12:21:52 UTC

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