[webkit-dev] XHR responseArrayBuffer attribute

[Chris Marrin]

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
cmarrin at apple.com