Re: Data racing proposals

On Wed, Jul 31, 2013 at 5:06 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

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

Rampant intellectual property theft!  I am appalled!  Oh wait, no I'm not.


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

I'm slightly confused, so let me expand a few examples.  I can see (at
least) three cases:

1) I've assigned the .buffer [presume we're using your original semantics],
then I call .getChannelData and postMessage the ArrayBuffer to a worker.
 In this case, I think the assignment acquired the contents, but the
.getChannelData copied the data, so the postMessaged data is complete but
the AudioBuffer's ArrayBuffer got neutered.

2) I called .getChannelData and postMessage prior to assigning the .buffer.
 In this case, I think the audio thread's acquire is called on a neutered
ArrayBuffer, so it's empty and plays nothing.

3) I called .getChannelData, kept a reference to it, assigned the buffer,
then tried to postMessage the ArrayBuffer I'd been holding on to.  In this
case, I think the assignment neutered the reference, so the postMessage
gets an empty array.  (I think this is the case you're referring to above.)

Are those all correct?

"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 :-).
>

Fair enough.  But this is a [large-memory-chunk-holding] layer on TOP of
GC, with different semantics and triggers.  And GC to begin with is hard
enough.  :)


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

Fair enough.

-C

PS I'm heading off on vacation early tomorrow morning, so I will be less
responsive while travelling.