W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]

From: David Levin <levin@chromium.org>
Date: Thu, 2 Jun 2011 23:43:17 -0700
Message-ID: <BANLkTi=Gemv5ZvHrNyPOUpBh2ehd59oxug@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Glenn Maynard <glenn@zewt.org>, Kenneth Russell <kbr@google.com>, ben turner <bent.mozilla@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Thu, Jun 2, 2011 at 10:17 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Jun 2, 2011 at 4:41 PM, David Levin <levin@chromium.org> wrote:
> >> None of the objects which allow transferring of ownership has children
> >> so this doesn't appear to be a problem at this time. If it indeed does
> >> turn into a problem, it would seem like a problem no matter what
> >> solution is used, no?
> >
> > Not if all objects are transferred.
> Define "all objects". Consider something like:
> a = { x: myArrayBuffer1, y: myArrayBuffer2 };
> worker.postMessage(a, { transfer: true });
> In this case the 'a' object is obviously not transferred. Or are you
> proposing that it'd be transferred too somehow?

Well the algorithm could empty 'a'. As far as what happens underneath the
covers that is up to the implementation. (I suspect most javascript engines
today wouldn't allow for actually transferring the memory cross thread.)

> > Here's a simple use case, suppose I create an array of arrays (a 2d
> array)
> > which contains ArrayBuffers.Now I want to transfer this as fast as
> possible
> > using postMessage.
> > What does my code look like for each of these apis?
> Your proposal:
> w.postMessage(my2darray, {transfer: true});
> vs.
> w.postMessage(my2darray, Array.concat.apply(Array, my2darray));

I thought this would be:
   w.postMessage(my2darray, {transfer: Array.concat.apply(Array,

> Now show me the code needed to send a message which contains one big
> buffer from you that you want to transfer, along with some data that
> you got from some other piece of code and which you do not want to
> modify and which may or may not contain ArrayBuffers.

Fair enough. Way more complicated for the "transfer: true" case. :)

The thing that seemed odd to me about this extra array is that it seemed to
make the code more complicated and harder to understand.  However, I
understand that folks want to support involved scenarios.

*Let's go with the transfer list.* (I suspect that something like transfer:
true or transfer: "all" would still be possible in the future if it proved
desirable since bools/strings won't be valid there.)

Received on Friday, 3 June 2011 06:44:07 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:32 UTC