On Tue, Sep 28, 2010 at 9:45 AM, Maciej Stachowiak <m...@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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to