Re: Proposal for fixing race conditions

On Wed, Jul 17, 2013 at 2:24 PM, Srikumar Karaikudi Subramanian <
srikumarks@gmail.com> wrote:

> Your hypothetical test case merely demonstrates the difference; my point
> is that it is silly to optimize for imaginary edge cases at the cost of
> real-world use cases where developers will get unexpected results due to
> leaving race conditions in this API. I should also note that it has come up
> in past discussions that we could always introduce new no-copy APIs that
> don't contain races, if the cost of memcpy is so severe.
>
>
> It is not inconceivable to make an audio editor which plays an audio file
> from a specific sample onwards by assigning the buffer to an
> AudioBufferSourceNode and using start(t,offset,duration) ... possibly
> followed by effects. Large files (even 5mins?) would be unusable with such
> an editor if a copy were involved and clients/devs will be forced to do
> crazy optimizations just to get it to work.
>

Are you suggesting the editor would play the audio data while
simultaneously allowing the user to edit it?

If so, that's a good example of how race conditions are likely to lead to
bizarre and unpredictable behavior.

If not, then if my proposal is adopted, a browser could handle this case
efficiently. When a stop() call means the audio thread no longer needs
access to a buffer, the memory can be returned to the AudioBufferSourceNode
so that the next call to getChannelData() can use that memory again instead
of copying it.

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