On Thu, Sep 30, 2010 at 11:51 AM, Chris Marrin <cmar...@apple.com> wrote: > > On Sep 30, 2010, at 10:46 AM, Kenneth Russell wrote: > >>> ... >>> >>> 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. > > There are many ways to do it. If we do it as a read-only property, then we > need to do a write check on every access.
This is incorrect. The view hierarchy can be split into read-only and read-write versions, and attachment of a read-write view to a read-only ArrayBuffer specified to throw an exception. Splitting ArrayBuffer into two classes is much more traumatic. We should probably continue this discussion on public_webgl since I suspect it isn't of interest to the majority of webkit-dev subscribers. -Ken > Doing it as a completely set of immutable classes (ArrayBuffer and views) > would double the number of classes. But there are only 9 classes now, so the > increase wouldn't be that bad. This is especially true with the way the spec > is now. All the views are collapsed into a single section. So we're really > just talking about adding 2 new sections, plus a description of the > semantics, the new makeImmutable() function on ArrayBuffer and probably some > copy functions. > > ----- > ~Chris > cmar...@apple.com > > > > > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
