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
