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

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:
> >>
> >>>However, another consideration is that the WebGL spec isn't ES specific,
> >>> and yet has to depend on typed arrays.  So perhaps we're really talking
> >>> about two different specs: a main typed array spec that uses Web IDL
> and can
> >>> be implemented generically in any language, as well as a separate spec
> >>> describing ES types that happen to fulfill the requirements of typed
> arrays.
> >>
> >> If that is a concern, how do you expect these interfaces to work with
> other
> >> languages.  In a C++ binding are the view objects and the buffer objects
> >> still going be distinct objects or are you expect to merge them into
> native
> >> C++ objects.   I think that there is a pretty fundamental question here:
> >> does your (and similar) application need to expose binary buffers that
> exist
> >> natively in the  implementation technology of your subsystem and which
> can
> >> be interchange among multiple client languages.  Or, are you able and
> >> willing to directly work with native JavaScript buffer objects (assuming
> >> that such things exist) even it that a less natural form of access on
> your
> >> part.  In the first case, “host objects” may be exactly what you need.
> If
> >> the second is what you would like, then we probably need a EcmaScript
> >> extension.
> >
> > 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.

http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html
http://erights.org/talks/promises/
http://nodejs.org/#about
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html
and many many others...

There are two relevant quality metrics here -- correctness and performance.
At this point, I think shared state concurrency has rather definitively lost
the correctness argument. Correctness aside, the jury is till out on the
performance argument. (If the program doesn't need to be correct, I can make
it arbitrarily fast anyway.) NodeJS, NGINX, and others show that event loops
can be quite competitive on performance, and can beat the hell out of
conventional threading systems.

In any case, JavaScript isn't C. For most everyone who's moved on from C and
C++, paying a minor performance cost in exchange for massively unburdening
the cognitive load on the programmer is considered a good tradeoff. Among
these post-C languages, Java's greatest mistake is committing to the shared
state concurrency control model. JavaScript has wisely avoided that mistake.

With browsers talking to servers, servers talking to servers, browser frames
talking to browser frames with postMessage, and with workers, JavaScript is
already doing communicating event loops, even though this choice is not yet
found in JavaScript's official semantics. Communicating event loops is a
scalable model of concurrency, parallelism, and distributed computing.
JavaScript has already made its choice. Let's make the most of it. Mixing
models at this point will only give us the worst of both worlds.

At some point I would like to see communicating event loops become an
official part of JavaScript's semantics. However, I am not arguing to make
that official at this time. We have enough on our plate for ES-next without
adding this at this time. However, let's not preclude it either.


>
> > In the Java platform, the NIO buffer classes provide similar
> > functionality, and provide a bridge to the outside world. The Java
> > APIs [1] specify how values can be fetched and stored in the buffers.
> > A few entry points in the Java Native Interface [2] specify how
> > external C code can wrap a region of memory in a NIO buffer and
> > thereby expose it to Java. If it were possible to specify similar
> > functionality in an ECMAScript extension, I think it would enable all
> > of the use cases mentioned above.
> >
> > -Ken
> >
> > [1] http://java.sun.com/javase/6/docs/api/java/nio/package-summary.html
> > [2]
> http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM