Support Transferable objects

This is the pure-Chromium side for the WebKit patch detailed at https://bugs.webkit.org/show_bug.cgi?id=65209 . This patch can compile independently of that WebKit patch; it contains some temporary preprocessor blocks to accomplish this.

The Structured Clone algorithm describes an interface for Transferable objects (http://www.whatwg.org/specs/web-apps/current-work/complete/common-dom-interfaces.html#transferable-objects). Currently the only official Transferable object is the MessagePort, but ArrayBuffers are expected to be sanctioned as such soon. This is particularly important for Chrome because it will allow for cheap (copy-free) passing of ArrayBuffer data to and from in-process dedicated workers (once these land). ArrayBuffers are used heavily with WebGL; clients of that API have noted that they have found the existing implementation of message passing to be a little slow.

Imagine that we're trying to transfer an ArrayBuffer to a dedicated worker.
- JS calls postMessage(msg, [buffer]), where buffer is mentioned somewhere in msg.
- The ArrayBuffer backing the JS buffer is a Transferable; we transfer it out, getting back a TransferableReceipt that we can later exchange for an equivalent ArrayBuffer. The original Transferable is marked as closed.
- msg is serialized (with buffer being maintained as an external reference). The serialized msg and the TransferableReceipt for buffer are passed around together.
- Since we never touch IPC, we never need to copy the underlying array data; under the covers, it belongs to the TransferableReceipt.
- When it comes time to deserialize msg in the context of the destination dedicated worker, we exchange buffer's TransferableReceipt back for its promised Transferable-- an ArrayBuffer that takes control of the original array's memory.

If it turns out that the message needs to cross an IPC boundary, some TransferableReceipts will need to be flattened-- that is, the IPC system will redeem them and paste the data they contain to the beginning of the serialized message. Note that certain Transferables have special semantics (like MessagePorts) under which it either doesn't make sense or isn't useful to clone the objects in this way. This flattening happens just before the message gets sent out (because at the time the message is generated there isn't a clear way to determine that it will eventually need to travel across an IPC boundary).

[zarko, 2011-07-29 23:10:36]

This change is part of an effort in making ArrayBuffer passing to and from
dedicated workers fast. Please take a look when you get a chance!

Thanks
  Luke

[jam, 2011-08-01 06:24:56]

Can you add some background in the description of the change (since that's what
goes into the changelog). I haven't heard of this change before, so it's very
new to me and I'm not familiar with the goals/names etc.

to nit, no need for blank BUG= and TEST lines. BUG= is when you have a bug
number. If there isn't one, then you don't need it. TEST= is when you have
manual test instructions for the test team.

http://codereview.chromium.org/7477027/diff/7001/content/common/webmessagepor...
File content/common/webmessageportchannel_impl.h (right):

http://codereview.chromium.org/7477027/diff/7001/content/common/webmessagepor...
content/common/webmessageportchannel_impl.h:23: typedef WebMessagePortChannel
WebTransferableReceipt;
I'm curious how these WebKit names have been picked, since transferable receipt
is cryptic for someone seeing it for the first time. You'll need Darin to review
the WebKit API, so I'll defer to him on naming

http://codereview.chromium.org/7477027/diff/7001/content/renderer/webworker_p...
File content/renderer/webworker_proxy.cc (right):

http://codereview.chromium.org/7477027/diff/7001/content/renderer/webworker_p...
content/renderer/webworker_proxy.cc:74: size_t unflattenableCount;
nit: chrome style is lower case variable names with underscores (also below)

[zarko, 2011-08-01 23:04:50]

On 2011/08/01 06:24:56, John Abd-El-Malek wrote:
> Can you add some background in the description of the change (since that's
what
> goes into the changelog). I haven't heard of this change before, so it's very
> new to me and I'm not familiar with the goals/names etc.
> 
> to nit, no need for blank BUG= and TEST lines. BUG= is when you have a bug
> number. If there isn't one, then you don't need it. TEST= is when you have
> manual test instructions for the test team.

I've updated the description-- please let me know if more/less information would
be useful. I also hope that it helps to explain the naming a little bit.

> 
>
http://codereview.chromium.org/7477027/diff/7001/content/common/webmessagepor...
> File content/common/webmessageportchannel_impl.h (right):
> 
>
http://codereview.chromium.org/7477027/diff/7001/content/common/webmessagepor...
> content/common/webmessageportchannel_impl.h:23: typedef WebMessagePortChannel
> WebTransferableReceipt;
> I'm curious how these WebKit names have been picked, since transferable
receipt
> is cryptic for someone seeing it for the first time. You'll need Darin to
review
> the WebKit API, so I'll defer to him on naming
> 
>
http://codereview.chromium.org/7477027/diff/7001/content/renderer/webworker_p...
> File content/renderer/webworker_proxy.cc (right):
> 
>
http://codereview.chromium.org/7477027/diff/7001/content/renderer/webworker_p...
> content/renderer/webworker_proxy.cc:74: size_t unflattenableCount;
> nit: chrome style is lower case variable names with underscores (also below)

Got it; thanks!

[jam, 2011-08-02 05:43:43]

I see, thanks for the explanation, much clearer now.

Can I wait till WebKit folks are ok with it to review it?

[zarko, 2011-08-02 16:25:59]

On 2011/08/02 05:43:43, John Abd-El-Malek wrote:
> I see, thanks for the explanation, much clearer now.
> 
> Can I wait till WebKit folks are ok with it to review it?

Sure-- the WebKit reviews might change some interfaces after all. This patch
will need to land before the WebKit side does, though (because of the
aforementioned interface changes).