On Wed, Sep 29, 2010 at 6:34 PM, Maciej Stachowiak <m...@apple.com> wrote: > > On Sep 29, 2010, at 2:02 PM, Kenneth Russell wrote: > >> On Tue, Sep 28, 2010 at 11:26 AM, Maciej Stachowiak <m...@apple.com> wrote: >>> >>> On Sep 28, 2010, at 11:05 AM, Kenneth Russell wrote: >>> >>>> 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. >>> >>> Not if the side that got the data got it in immutable form in the first >>> place. For example, if you get an immutable ArrayBuffer from XHR in a >>> Worker, then you can pass it to another Worker or to the main thread >>> without the need for any copying or copy-on-write. >>> >>>> >>>> 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. >>> >>> I'm curious to hear it and I don't follow public_webgl. >>> >>> I'd specifically like to handle the following case: >>> - You obtain a chunk of binary data from the network or filesystem and want >>> to pass it to another thread without copying. >> >> The scenario to which I've given the most thought is that where a >> continuous stream of data is sent from a worker to the main thread, >> vice versa, or back and forth. I'll describe the solution for this >> case first and then discuss how it applies to yours. >> >> In the producer/consumer scenario it is essential to avoid continuous >> memory allocation and deallocation. Ideally the main thread and worker >> would share a fixed size memory region. Since this would violate the >> shared-nothing semantic, a different solution is needed. >> >> The idea is that when an ArrayBuffer is sent via postMessage, it is >> atomically "closed" on this side; its publicly visible length goes to >> 0, as do the lengths of any views referring to it. On the other side, >> a new ArrayBuffer wrapper object is synthesized, pointing to the same >> storage and with the original length. >> >> To be able to reuse the same memory region over and over again, the >> other side would simply send the ArrayBuffer back for re-filling via >> postMessage. Ping-ponging ArrayBuffers back and forth achieves >> zero-copy transfer of large amounts of data while still maintaining >> the shared-nothing semantic. The only allocations are for the (tiny) >> ArrayBuffer wrapper objects, but the underlying storage is stable. >> >> Implementing this idea will require a couple of minor additions to the >> TypedArray specification (in particular, the addition of a "close" >> method on ArrayBuffer) as well as defining the semantics of sending an >> ArrayBuffer via postMessage. I hope to prototype it soon. >> >> Regarding your scenario, I would simply post the ArrayBuffer from the >> XHR object to the worker with the above semantics. The main thread >> would then not be able to access the data in the ArrayBuffer, but >> sending it to the worker for processing would not involve any data >> copies. > > Sure, transfer semantics avoid shared mutable state, though it would be > inconsistent with most other "pure data" types. But what if you have some > data that doesn't need mutating but you'd like to share with multiple other > Workers? Now you'd be forced to explicitly copy. The availability of an > immutable variant would let you avoid that. At most, you'd need to copy once > if your ArrayBuffer started immutable; or you could have the ability to > convert mutable to immutable at runtime (it would have to be a one-way > conversion, of course). > >> >> I don't understand why the ArrayBuffer returned from the XHR needs to >> be strictly immutable. Since the application created the XHR object, >> it seems to me it should be fine if it mutates the copy of the data >> attached to it. > > If the reference is immutable, then you can share the backing store with the > cache. If it's mutable, at best you can do copy-on-write. > > If the reference is mutable, then multiple independent pieces of code can't > safely share the binary response from the same XHR. They would have to copy. > > It also seems just plain surprising that you get get the response from XHR, > modify it (perhaps thinking it is a private copy), and then if you re-get it > later, it still shows the changes. responseText doesn't act that way. It > would be even more weird that if you pass the response to a worker, you lose > access to it unless you explicitly copied (assuming your transfer proposal).
Well, responseText doesn't act that way because it's a string, and therefore immutable anyway. That being said, clearly there are uses for both mutable and immutable ArrayBuffers. > Immutability lets you avoid a bunch of copying, and in the (likely) rare case > where you want to mutate the binary response data, you can make a copy only > when actually needed, instead of imposing costs on clients that only want to > read. > > Regards, > Maciej > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
