On Thu, Sep 30, 2010 at 7:09 AM, Chris Marrin <cmar...@apple.com> wrote: > > On Sep 29, 2010, at 6:34 PM, Maciej Stachowiak wrote: > > ...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'm thinking about how this would be implemented. Ken talks about a "close" > function to make it possible to pass an ArrayBuffer to a worker. If I have > it right, this would detach the contents of the ArrayBuffer from it's owning > object, replacing it with a 0 length buffer. Then the worker attaches the > contents to a new ArrayBuffer owned by the worker. To do that we'd need to > figure out the "magic" of passing this bare buffer to the worker. An > ImmutableArrayBuffer would not need any such magic. But without any > additional functionality, you'd always need an additional copy (even it's a > copy-on-write) for Maciej's example. > In Maciej's example, he wants to take an incoming buffer and pass it to a > worker, presumably so it can be mutated into something else. So you'd pass > the ImmutableArrayBuffer to the worker (no copy) and it would create a new > ArrayBuffer with one or more views which it would fill with the mutated > data. But to pass this buffer back to the main thread, you'd need to convert > this ArrayBuffer to an ImmutableArrayBuffer, which would require some sort > of copy. > What's needed is a way to pass that ArrayBuffer back to the main thread > without a copy. So maybe we just need a function like Ken's "close" but > without the magic. A makeImmutable() function could be called on the > ArrayBuffer, which would create a new ImmutableArrayBuffer, attach the > contents of the ArrayBuffer to it and set the contents of the ArrayBuffer to > a 0 length buffer, as in Ken's design. > So now you'd pass the incoming ImmutableArrayBuffer to the worker, create a > new ArrayBuffer for the mutated data, fill it, call makeImmutable on it and > return the result. No copies would be needed. Once the process starts, the > old buffers can be recycled to avoid memory allocations as well. > Would something like that work?
I can see the need both for immutable data and transfer semantics. I don't think that adding a new type (ImmutableArrayBuffer) is the right way to do it, because it significantly complicates the type hierarchy. Rather, I think immutability should be a read-only property on the ArrayBuffer, set at creation time, and affecting the kinds of views that can be attached to it. I'll raise the issue and a proposal on the public_webgl mailing list. -Ken _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
