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

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