- From: Kenneth Russell <kbr@google.com>
- Date: Wed, 8 Sep 2010 18:37:36 -0700
- 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. -Ken
Received on Thursday, 9 September 2010 01:38:07 UTC