Proposal of Multithread JavaScript

Bradley Meck bradley.meck at
Wed Nov 2 13:57:00 UTC 2016

We need to be careful about this, I would never condone adding threading
that could share variables that were not intended to be multi-threaded, as
such variable access outside of your `parallelize` construct/syntax would
need to be message passing when talking to something that is not already
written as a parallel structure. A notable thing here is that Shared Memory
and Atomics that are in ECMA Stage 2 :
ecmascript_sharedmem which would probably need to land prior to me
condoning any shared mutable state.

Historically, all JS implementations are based upon a job queueing system
described by the Event Loop. This is very different from parallelism which
could have shared mutable state. All code is guaranteed to have exclusive
access to variables in scope until it finishes running, and that the
content of those variables will not change from preemption (there are cases
where this is not true in the browser with a live DOM). There are
alternative discussion recently on Workers :
standardize-es-worker . I might look there first.

In particular, I would suggest taking a look at problems of
synchronization, locking, and preemption breaking existing code a bit
rather than just stating that green threads are the way to go.

On Wed, Nov 2, 2016 at 8:45 AM, Leo Dutra < at> wrote:

> ECMA introduced Promises and async-await in JS. This improves coding in an
> amazing way, reducing the control developers need to wrap an AJAX call or
> async I/O.
> JavaScript used to be script and not a language. Classes, workers, sound
> control, GL rendering, Node.js modules (with OS conversation), incredible
> GC strategies and compilation on V8 and Mozilla "monkeys"... the list goes
> on and on.
> Almost all the features provided by old mature platforms, like Java, .NET
> and etc. For browsers, the newest JS features provide consistent tools for
> productivity and quality code.
> But there's a huge step to accomplish.
> ECMA introduced workers. Node.js came up with streams, native process
> spawn and libuv thread pool. This is a lot, but not enough.
> All I hear about Node.js is how it is great for quick message I/O and bad
> for aggregations and impossible for parallel tasking. Again, we have
> workers and processes, but not green threads.
> I invite you to take a quick look at Akka and OTP (Erlang). More than it,
> I will argument: workers and process spawn are the latent desire for
> parallel and starting one of these are not "cheap" or waiting in a pool.
> We use streams extensively in Node.js and most frameworks hides it from
> us. Call it magic, I call it pragmatism.
> Now, async, await, Promises ("Futures")... we can make it all work in
> parallel.
> This would explore more libuv in Node.js and browsers could handle it too,
> seamlessly.
> Each function could be run in a green thread, pulled from a browser/libuv
> pool, allowing Node.js and browsers to process aggregations and heavy
> rendering without heavy start costs and complicated message control through
> events.
> More, I ask why not, and "single thread nature of JS" looks more like a
> bad legacy from old browsers. We can do it in pieces, like the proposed
> async-await and, on better days, provide a Parallel API (something like *parallelize(()
> -> { // parallel stuff here })*).
> I wanna leave you with the possibilities in mind and bully this single
> thread dogma.
> You have been told.
> *Leo Dutra, **on **Facebook <> **and LinkedIn
> <>*
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list