W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [whatwg] ArrayBuffer and ByteArray questions

From: Kenneth Russell <kbr@google.com>
Date: Wed, 8 Sep 2010 18:37:36 -0700
Message-ID: <AANLkTim0b8Z=7mmRBKsxKmsGYXStK1Bs8UF4wdJVK1PW@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: Chris Marrin <cmarrin@apple.com>, Oliver Hunt <oliver@apple.com>, whatwg@lists.whatwg.org, Web Applications Working Group WG <public-webapps@w3.org>, Simon Pieters <simonp@opera.com>
On Wed, Sep 8, 2010 at 5:04 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Thu, Sep 9, 2010 at 4:37 AM, Chris Marrin <cmarrin@apple.com> wrote:
>> On Sep 8, 2010, at 11:21 AM, Oliver Hunt wrote:
>> >
>> > On Sep 8, 2010, at 11:13 AM, Chris Marrin wrote:
>> >
>> >> Web Sockets is certainly another candidate, but I meant Web Workers.
>> >> There have been informal discussions on using ArrayBuffers as a way to
>> >> safely share binary data between threads. I don't believe anything has been
>> >> formalized here.
>> >
>> > You can't share data between workers.  There is no (and there cannot be)
>> > any shared state between multiple threads of JS execution.
>> Right. I didn't mean literal sharing. But you can imagine some
>> copy-on-write semantics which would make it more efficient to pass data this
>> way.
> Is this then similar to posting ImageData with Web Workers?
> (http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#imagedata)
> . I know that these can already be put into a postMessage and they are
> effectively arrays.

It's similar, but we want to define different semantics to achieve
higher performance. Copy-on-write does not work because in a
producer/consumer scenario the producer will always overwrite the same
buffer passed to the consumer, leading to a copy each time. We want to
make the source ArrayBuffer, and any ArrayBufferViews, zero length
upon posting them to a worker or back to the main thread. By
ping-ponging the same ArrayBuffer back and forth you can avoid
allocating new backing store each iteration.

Received on Thursday, 9 September 2010 01:38:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:11 UTC