Re: Data racing proposals

On Thu, Aug 1, 2013 at 4:09 AM, Chris Wilson <cwilso@google.com> wrote:

> On Tue, Jul 30, 2013 at 6:53 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>  and they need to do something different with the ArrayBuffer returned
>>> from getChannelData (i.e. re-assign it to another AudioBuffer);
>>>
>>
>> That's not correct. With my proposal, when getChannelData is called while
>> or after an AudioBuffer is in use, the app can modify the Float32Array and
>> then reuse the same AudioBuffer with those modifications taken into account.
>>
>
> I think I now finally understand at least part of the subtlety in your
> proposal.  It was not clear to me that when the lazy copy was created,
> you're essentially orphaning the audio thread's copy of the buffer from the
> AudioBuffer, not the AudioBuffer's [lazily-created] copy.  That does make
> more sense.  The concept of "acquiring" implied an ownership that was
> confusing.
>

I think once Jer's proposal has been precisely nailed down, I'll rewrite
mine into the same format so it's easy to understand the relationship.


> I think we could improve this approach a bit. We don't really need a
>> Promise here since AudioBuffer contents are expected to be in memory. It
>> would also be good to be able to reuse an existing Float32Array instead of
>> having to allocate a new one. So I'd suggest something like "void
>> copyTo(Float32Array dest, long offset, long length)" instead.
>>
>
> See below on async.  On reusing Float32Array: then you need to handle
> channel selection too (buffer may be multi-channel, you will need to copyTo
> for each channel's Float32Buffer), which is why I didn't do this.  I can
> see the value, though.
>

Yes, there should be a channel parameter there. I think if you want to
minimize memory usage, you'd better go all the way and enable reuse of an
existing array.

I think I might steal this extension for my proposal too :-).

You should confirm or elaborate: I think in your proposal, if I post to
> another thread prior to assigning the .buffer, the AudioBuffer's contents
> are simply neutered; if I post to another thread after assigning, the audio
> thread can still play (the lazy copy created another copy when asked for
> getChannelData to transfer, then transferred that copy), but the
> AudioBuffer's contents will still be neutered (since its shared copy was
> neutered).
>

If the ArrayBuffer is transferred to another thread before the "acquire the
contents" operation, "acquire the contents" gets a zero-length buffer and
nothing gets played. If it is transferred to another thread after the
"acquire the contents" operation, the "acquire the contents" operation
neutered the ArrayBuffer so an empty array is transferred to the other
thread.

"Magic memory usage improvement happens sometimes" is the bit that concerns
> me.  It may not be observable in the sense of "I can write code that sees
> it directly", but it is going to change the memory footprint pattern
> dramatically.  Personally, I think this kind of magic makes the web
> platform harder to use than some sharing of memory.
>

"Magic memory usage improvement happens sometimes" describes garbage
collection in general :-).

IMHO if most apps on most hardware don't need to worry about memory usage
in this case, presenting them with a simpler interface is best even if its
performance characteristics are more "magical". For the remaining apps, the
spec should guide them towards APIs that minimize memory usage, such as
copyTo.

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