Proposal of Multithread JavaScript

Leo Dutra leodutra.br at gmail.com
Wed Nov 2 14:23:30 UTC 2016


​Understood about shared mem. I agree a declared shared space is faster and
more manageable than a considering all shared.

As I said, we could use JIT to determine that or use the long reserved word
"volatile":
volatile var foo = "Shared string"

Accessing a non-volatile variable SHALL resolve to a copy like all the
other platforms resolve.

I don't like to refer to others, but this is a problem industry resolved a
long time ago.
​


*Leo Dutra, **on **Facebook <http://www.facebook.com/leodutra.br>
**and LinkedIn
<https://www.linkedin.com/in/leobr>*

2016-11-02 12:22 GMT-02:00 Leo Dutra <leodutra.br at gmail.com>:

> Understood about shared mem. I agree a declared shared space is faster and
> more manageable than a considering all shared.
>
> As I said, we could use JIT to determine that or use the long reserved
> word "volatile":
> volatile var foo = "Shared string"
>
> Accessing a non-volatile variable SHALL resolve to a copy like all the
> other platforms resolve.
>
> I don't like to refer to others, but this is a problem industry resolved a
> long time ago.
>
>
>
>
>
> *Leo Dutra, **on **Facebook <http://www.facebook.com/leodutra.br> **and LinkedIn
> <https://www.linkedin.com/in/leobr>*
>
> 2016-11-02 11:57 GMT-02:00 Bradley Meck <bradley.meck at gmail.com>:
>
>> 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 : https://github.com/tc39/ecma
>> 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 : https://esdiscuss.org/topic/
>> 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 <leodutra.br at gmail.com> 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 <http://www.facebook.com/leodutra.br> **and LinkedIn
>>> <https://www.linkedin.com/in/leobr>*
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161102/98c81098/attachment-0001.html>


More information about the es-discuss mailing list