[webkit-dev] XHR responseArrayBuffer attribute

[Kenneth Russell]

On Tue, Sep 28, 2010 at 9:45 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Sep 28, 2010, at 7:15 AM, Chris Marrin wrote:
>
>>
>> On Sep 27, 2010, at 6:37 PM, Maciej Stachowiak wrote:
>>
>>>
>>> On Sep 27, 2010, at 3:19 PM, Michael Nordman wrote:
>>>
>>>> Webkit's XHR currently does not keep two copies of the data that I can see. I think we should avoid that.
>>>
>>> We could keep the raw data around, which hopefully is directly usable as an ArrayBuffer backing store, and only translate it to text format when/if the client requests responseText.
>>
>> Yes, the raw data should be usable without translation in an ArrayBuffer. But we'd still need to make a copy of the raw bits when a new ArrayBuffer is created via responseArrayBuffer(), because that object is mutable.
>
> Is there an immutable variant of ArrayBuffer? If not, we really need one. But even without that, note that you don't necessarily need to make an immediate copy, you can use copy-on-write.
>
> The immutable variant would be helpful since we could avoid implementing threadsafe copy-on-write just to allow efficient passing of ArrayBuffers to Workers.

Chris has raised this issue on the public_webgl list, and we've begun
discussion there, but I would like to point out that having an
immutable ArrayBuffer and views on it does not help with the situation
of passing data to or from a web worker. The side that constructs the
data will necessarily have a mutable view, so it will be able to cause
changes that can be seen on the other side even if the view on the
other side is immutable.

We have a design that will allow efficient zero-copy producer/consumer
queues to be implemented using TypedArrays while maintaining
ECMAScript's shared-nothing semantics. I'll be happy to sketch it out,
but it's probably most appropriate for a mailing list like
public_webgl.

-Ken