[webkit-dev] XHR responseArrayBuffer attribute

[Kenneth Russell]

On Thu, Sep 30, 2010 at 11:51 AM, Chris Marrin <cmarrin at 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
> cmarrin at apple.com
>
>
>
>
>