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: Oliver Hunt <oliver@apple.com>
Date: Tue, 18 May 2010 09:14:07 -0700
Cc: Erik Corry <erik.corry@gmail.com>, "es-discuss@mozilla.org" <es-discuss@mozilla.org>, "arun@mozilla.com" <arun@mozilla.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Erik Arvidsson <erik.arvidsson@gmail.com>
Message-Id: <E559D826-DE16-437E-90E2-8D67CBE9AD14@apple.com>
To: Mark S. Miller <erights@google.com>

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)


Received on Tuesday, 18 May 2010 16:15:00 UTC

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