W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2010

Re: No Shared State Concurrency in JS (was: Adoption of the Typed Array Specification)

From: Mark Seaborn <mseaborn@google.com>
Date: Tue, 18 May 2010 22:15:17 +0100
Message-ID: <AANLkTik7a6Y4AYqX8pzaa2f96OLDb7aYeeMAxXunz7um@mail.gmail.com>
To: Kenneth Russell <kbr@google.com>
Cc: "Mark S. Miller" <erights@google.com>, "arun@mozilla.com" <arun@mozilla.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Erik Arvidsson <erik.arvidsson@gmail.com>, "es-discuss@mozilla.org" <es-discuss@mozilla.org>
On Tue, May 18, 2010 at 9:52 PM, Kenneth Russell <kbr@google.com> wrote:
> On Tue, May 18, 2010 at 9:23 AM, Mark S. Miller <erights@google.com> wrote:
>> Whew. Yes, copy-on-write sharing with workers is a great idea. IIUC, it
>> should be a completely transparent, semantics free optimization. Thanks for
>> clearing that up.
> I hesitate to mention this, but outside of the WebGL working group
> some colleagues and I have discussed using a combination of shared
> buffers and postMessage semantics to achieve direct sharing of
> buffers' contents. The use case is that a worker repeatedly produces
> new vertex data to be consumed by the main thread. Without the ability
> to share one or more buffers directly, the worker thread must
> repeatedly allocate new storage to be handed off to the main thread.
> If the main thread does not promptly deallocate this storage, the
> system will rapidly exhaust available resources.

Couldn't you provide a fast channel object that is implemented using
shared memory, but hide the fact that it is using this buffer, so that
only message-passing semantics are exposed?

Received on Tuesday, 18 May 2010 21:29:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC