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. 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