Proposal of Multithread JavaScript

Florian Bösch pyalot at
Wed Nov 2 14:55:08 UTC 2016

I'd like to quickly point out that Promises, async/await are actually
implementations of co-routines. Unlike true co-routines however they're
infective (once something down the call stack becomes a promise or an
async, it infects upwards). They have none of the conveniences of actual
co-routines (non infective, control flow/structural semantic is preserved),
while sharing all of the drawbacks of any other cooperative multitasking
scheme (data corruption).

Racing in promises:

xhr().then(function(){a.text = 'foo'})
xhr().then(function(){a.text += 'bar'})

Racing in async/await:

async function foo(){ a.text = await xhr(); }
async function bar(){ a.text += await xhr(); }
await* [foo(), bar()]

Racing with cooperative multitasking (assuming greenlet semantics and a
trampoline I/O scheduler):

  a.text = xhr();
  a.text += xhr();

None of these examples is really representative of what people would
actually do, which is:


    a.text = 'foo';
    return xhr();
    a.text += 'bar';


a.text = await xhr();
a.text += await xhr();


a.text = xhr();
a.text += xhr();

However we can see how actual co-routines would have a marked advantage in
simplicity and conciseness.

All forms of cooperative multitasking would eventually have to evolve a
barrier mechanism to deal with data corruption. Promises are severely
handycapped in that regard as they cannot create barriers at all.
Async/await barriers are conceivable, but awkward. Co-routine barriers are
relatively straightforward to implement if you control your scheduler

It should be noted that controlling what kind of scheduler you use would be
kinda important, which is one convenient aspect of co-routines, they can
easily implement a custom one fit for your needs.

On Wed, Nov 2, 2016 at 3:27 PM, Bradley Meck <bradley.meck at> wrote:

> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list