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 13:52:27 -0700
Message-ID: <AANLkTinjZXs4LpZjiD0JHjUA2AOVBtccFukbXrwMwVpx@mail.gmail.com>
To: "Mark S. Miller" <erights@google.com>
Cc: Oliver Hunt <oliver@apple.com>, "arun@mozilla.com" <arun@mozilla.com>, "es-discuss@mozilla.org" <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Erik Arvidsson <erik.arvidsson@gmail.com>
On Tue, May 18, 2010 at 9:23 AM, Mark S. Miller <erights@google.com> wrote:
> On Tue, May 18, 2010 at 9:14 AM, Oliver Hunt <oliver@apple.com> wrote:
>>
>> On May 18, 2010, at 9:04 AM, Mark S. Miller wrote:
>>
>> On Tue, May 18, 2010 at 12:22 AM, Erik Corry <erik.corry@gmail.com> wrote:
>>>
>>> 2010/5/18 Kenneth Russell <kbr@google.com>:
>>> > On Thu, May 13, 2010 at 8:28 PM, Allen Wirfs-Brock
>>> > <Allen.Wirfs-Brock@microsoft.com> wrote:
>>> >>> Vladimir Vukicevic vladimir@mozilla.com said:
>>>  > Using hypothetical native JavaScript buffer objects would be
>>> > compatible with our current relatively simple use of TypedArrays.
>>> > However, we have begun to explore more advanced use cases including
>>> > sharing TypedArrays among web workers, and between ECMAScript and
>>> > browser plugins. In these situations, if we were to use native
>>> > JavaScript buffer objects, we would need to specify additional
>>> > behavior for the objects.
>>>
>>> This looks like a can of worms to me.  Shared buffers break with the
>>> shared-nothing and message-passing paradigms and necessitate
>>> synchronization primitives.
>>
>> +1.
>>
>> There has not been any suggestion of concurrent access to the same shared
>> buffer that i am aware of (otherwise i would have called this out in the
>> WebGL WG) -- the only thing that has been discussed is interaction with
>> workers, where we sharing of the underlying data buffer was always couched
>> in terms of copy-on-write semantics (eg. make the cloning fast by avoiding
>> cloning if possible)
>
> 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.

We are interested in doing some prototypes to see what works.
Currently I would not like to specify any behavior in this area or
artificially limit the ability to experiment.

-Ken
Received on Tuesday, 18 May 2010 20:53:24 UTC

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