Proposal of Multithread JavaScript

Leo Dutra at
Wed Nov 2 14:39:18 UTC 2016

If it is accepted, yes... Atomics should take care of racing.

We have a lighter context than most functional languages with this
proposal: we reassure JavaScript memory is totally mutable (against

This keeps the job easier. I was thinking in the worst possibility and we
have the easier.

Lock, immutability and not shared mutation are the special cases.
For these cases, Atomic and Mutex constructs will fit.

*Leo Dutra, **on **Facebook <>
**and LinkedIn

2016-11-02 12:27 GMT-02:00 Bradley Meck <bradley.meck at>:

> Consider:
> ```
> let a = {};
> alpha: parallel {
>   a.text = 'hello';
> }
> beta: parallel {
>   a.text += ' world';
> }
> console.log(a);
> ```
> This has racing:
> * around `a.text` between `alpha:` and `beta:`.
> * around `console.log` since `a` could be 1 of 3 values depending on how
> threads are scheduled.
> I am stating that such racing/shared mutation should be prevented. Workers
> do this by message passing and ownership of transferable data. There could
> be other mechanics for synchronization, but I don't see a simplistic
> solution. Things like having a read-only view of data partially helps, but
> atomics are most likely the proper way to do this if you don't want message
> passing and ownership semantics.
> On Wed, Nov 2, 2016 at 9:09 AM, Leo Dutra < at> wrote:
>> ​There's nothing about threading that is not problem with Event loop.
>> I'd say there's even less problems.
>> The proposal is a seamless behaviour, equals to what we have now.
>> Message passing is not a problem of JS developer in the case, but a
>> V8/WhateverMonkey problem.
>> Changing a value inside a multithread async MUST behave in the same way
>> of a change inside a single threaded async. The same way, non-referenced
>> variables SHALL NOT be scoped in the thread. This is not Java with
>> volatiles. This is the plain old JS with clojures, openess and loose bare
>> metal control.
>> Thread interruption is a bad practice anyway. And we could have a Mutex
>> class for the specific case or another idea.
>> Workers are evented and started, not pooled and easy to use.
>> *Leo Dutra, **on **Facebook <> **and LinkedIn
>> <>*
>> 2016-11-02 11:57 GMT-02:00 Bradley Meck <bradley.meck at>:
>>> 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 :
>>> script_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 :
>>> . 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