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: Kenneth Russell <kbr@google.com>
Date: Tue, 18 May 2010 14:38:21 -0700
Message-ID: <AANLkTikvTQQvqLSjlEsW_hE4XcgRf5T1zQalv-VKJzrJ@mail.gmail.com>
To: Mark Seaborn <mseaborn@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 2:15 PM, Mark Seaborn <mseaborn@google.com> wrote:
> 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?

Possibly. There is a large API design space. The difficulty is that
the current message passing semantics mandate allocation of storage on
the receiving end. If the API were structured to allow the receiver of
the message to read it into preexisting storage, that would address
some of the problem.

-Ken
Received on Tuesday, 18 May 2010 21:39:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:02 UTC