W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: Using ArrayBuffer as payload for binary data to/from Web Workers

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 9 Mar 2011 13:54:51 -0500
Message-ID: <AANLkTi=XB2obzF=F=tT5MOcC5EfkGJpFdxaiEY=A2HrA@mail.gmail.com>
To: Chris Marrin <cmarrin@apple.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Web Applications Working Group WG <public-webapps@w3.org>
On Wed, Mar 9, 2011 at 1:24 PM, Chris Marrin <cmarrin@apple.com> wrote:

> >> I don't recall if this has been brought up: are there cases where
> >> explicit zero-copy messaging is better than transparent copy-on-write?
> >
> > Transparent copy on write requires that each write do a "should I copy?"
> check, right?
>
> Yeah, nothing's free, unless you have copy-on-write hardware or something.
>

Any system with memory protection can interrupt on write, which makes
copy-on-write very close to free, as long as you can page-align the buffer.

>> But how is this any different than just throwing away the ArrayBuffer and
creating a fresh one after each postMessage?
>
> You can't "throw away" the ArrayBuffer, since the sender still has a
reference to it. The proposal we've tossed around would make that
ArrayBuffer 0 length, which I suppose is conceptually throwing it away since
you can't add a fresh buffer to ArrayBuffer. So maybe it would be better if
ArrayBuffer still has the same length but now points at a new buffer of
data. This could be done lazily so the buffer need not be allocated until
accessed.

That's about the same thing, yes.  It seems like the mechanics necessary to
make copy-on-write work end up looking the same as zero-copy.  Given that,
copy-on-write only seems to add a layer of complexity to script engines.
So, I agree that an explicit zero-copy API is preferable.

-- 
Glenn Maynard
Received on Wednesday, 9 March 2011 18:55:24 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT