Re: Mutability of the decodeAudioData argument

On Mon, Nov 26, 2012 at 6:52 AM, Chris Rogers <crogers@google.com> wrote:

>
>
> On Thu, Nov 22, 2012 at 2:37 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> On Tue, Nov 20, 2012 at 2:43 PM, Chris Rogers <crogers@google.com> wrote:
>>
>>> On Mon, Nov 19, 2012 at 5:10 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>>>
>>>> Continuing from the discussion that roc started about the mutability of
>>>> AudioBuffers, we also need to specify what should happen if the author
>>>> tries to modify the ArrayBuffer argument of decodeAudioData.  If we want to
>>>> allow mutability, then the implementation either has to copy the buffer
>>>> eagerly or apply some kind of a copy on write mechanism on top of it, both
>>>> of which can be expensive for big buffers.
>>>>
>>>> Another approach which might make sense would be to neuter the
>>>> ArrayBuffer so that the author cannot access the contents of the
>>>> ArrayBuffer after starting a decode operation.
>>>>
>>>
>>>  I assume you mean neuter the buffer to be read-only, since writing to
>>> the ArrayBuffer in the main JS thread *while* the decoding is currently
>>> underway is what we're worried about?
>>>
>>
>> "Neutering the buffer to be read-only" isn't currently defined or
>> implemented anywhere, though.
>>
>> Instead of messing around with neutering, I also think that an
>>> implementation can simply make a temporary copy during the time it's
>>> decoding the data.  It can then release this copy of the undecoded data as
>>> soon as the decoding process has finished.  This way the memory-hit is
>>> temporary and is typically for a very short period of time.
>>>
>>
>> Don't you want to avoid having to copy the data?
>>
>
> First of all we need to determine if it's even necessary to worry about
> potential raciness with modifying the ArrayBuffer *while* it's being
> decoded.  At worst, I think it basically amounts to the JS code corrupting
> the data so that it would simply result in a decoding error.  This is not
> that much different from some JS code writing random bytes into the
> ArrayBuffer before the decode operation is started.  In either case, it's a
> pretty strange thing to do and a developer shouldn't be surprised if that
> results in a decoding error.
>

Sure there is. Pretty much nothing in JS threads is allowed to change state
during JS execution, otherwise it's considered a bug in the event loop and
a violation of the HTML5 spec [1].


> Is there a problem with neutering the buffer?
>>
>
> If it were neutered, I'm foreseeing problems where developers keep the
> ArrayBuffer of undecoded audio data around and call decodeAudioData() a
> second time and it would fail.  It seems like there would be legitimate
> cases where it would be desirable to be able to re-decode if the originally
> decoded AudioBuffer is no longer available, has been garbage collected, etc.
>

I don't see where redecoding the ArrayBuffer wouldn't be a bug, after all
the ArrayBuffer would be restored from neutering after decoding is
complete, right? So redecoding would be fine after the previous decoding
operation has been completed; if the developer loses the decoded buffer
before that, it's probably a bug in his code. I'm not sure why the
developer would've kept the undecoded buffer around anyway; sure, for
compressed audio it takes less memory to keep the undecoded buffer instead
of the decoded one, but if the decoded one is hot you'll just end up using
more memory and if you eagerly discard the decoded buffer, more CPU as well.

Cheers,
Jussi

[1] http://dev.w3.org/html5/spec/webappapis.html#processing-model-3


>
>> Rob
>> --
>> Jesus called them together and said, “You know that the rulers of the
>> Gentiles lord it over them, and their high officials exercise authority
>> over them. Not so with you. Instead, whoever wants to become great among
>> you must be your servant, and whoever wants to be first must be your
>> slave — just as the Son of Man did not come to be served, but to serve,
>> and to give his life as a ransom for many.” [Matthew 20:25-28]
>>
>>
>