Proposal of Multithread JavaScript

classic Classic list List threaded Threaded
79 messages Options
1234
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposal of Multithread JavaScript

Leo Dutra
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 Dutraon Facebook and LinkedIn

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Leo Dutra
TL;DR:

(function foo() { ... })()   // sync and single threaded
(async function() { ... })() // async and parallel

Additional:
parallel.run()
parallel.stream()
parallel.sleep()
parallel.waterfall()
...



Leo Dutraon Facebook and LinkedIn

2016-11-02 11:38 GMT-02:00 Leo Dutra <[hidden email]>:
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 Dutraon Facebook and LinkedIn


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Bradley Meck
In reply to this post by Leo Dutra
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/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 : 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 <[hidden email]> 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 Dutraon Facebook and LinkedIn

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Leo Dutra
​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 Dutraon Facebook and LinkedIn

2016-11-02 11:57 GMT-02:00 Bradley Meck <[hidden email]>:
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/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 : 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 <[hidden email]> 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 Dutraon Facebook and LinkedIn

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Leo Dutra
In reply to this post by Bradley Meck
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 Dutraon Facebook and LinkedIn

2016-11-02 12:22 GMT-02:00 Leo Dutra <[hidden email]>:
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 Dutraon Facebook and LinkedIn

2016-11-02 11:57 GMT-02:00 Bradley Meck <[hidden email]>:
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/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 : 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 <[hidden email]> 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 Dutraon Facebook and LinkedIn

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss





_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Bradley Meck
In reply to this post by Leo Dutra
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 <[hidden email]> 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 Dutraon Facebook and LinkedIn

2016-11-02 11:57 GMT-02:00 Bradley Meck <[hidden email]>:
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/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 : 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 <[hidden email]> 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 Dutraon Facebook and LinkedIn

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss





_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Leo Dutra
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 Erlang/Rust/Haskell).

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 Dutraon Facebook and LinkedIn

2016-11-02 12:27 GMT-02:00 Bradley Meck <[hidden email]>:
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 <[hidden email]> 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 Dutraon Facebook and LinkedIn

2016-11-02 11:57 GMT-02:00 Bradley Meck <[hidden email]>:
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/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 : 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 <[hidden email]> 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 Dutraon Facebook and LinkedIn

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss






_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Michał Wadas
Actually, is there any problem that can't be easily solved with message-passing for high-level structures or low-level shared memory buffers?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Leo Dutra
In reply to this post by Leo Dutra
This is not only easier, this is faster.

We have a single memory allocation and all the threads share it.
Considering your case:

let a = {};

async alpha() { a.text += 'hello' }
async beta() { a.text + ' world' }

parallel.all( a, b ) // or thread.parallel( a, b )
.then(x -> console.log(x))

Will output ' worldhello' or 'hello world' like any multithread platform will.



Leo Dutraon Facebook and LinkedIn

2016-11-02 12:39 GMT-02:00 Leo Dutra <[hidden email]>:
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 Erlang/Rust/Haskell).

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 Dutraon Facebook and LinkedIn

2016-11-02 12:27 GMT-02:00 Bradley Meck <[hidden email]>:
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 <[hidden email]> 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 Dutraon Facebook and LinkedIn

2016-11-02 11:57 GMT-02:00 Bradley Meck <[hidden email]>:
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/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 : 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 <[hidden email]> 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 Dutraon Facebook and LinkedIn

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss







_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Leo Dutra
Sorry...

let a = {};

async alpha() { a.text += 'hello' }
async beta() { a.text + ' world' }

parallel.all( a, b ) // or thread.parallel( a, b )
.then(() -> console.log(a.text))


Leo Dutraon Facebook and LinkedIn

2016-11-02 12:46 GMT-02:00 Leo Dutra <[hidden email]>:
This is not only easier, this is faster.

We have a single memory allocation and all the threads share it.
Considering your case:

let a = {};

async alpha() { a.text += 'hello' }
async beta() { a.text + ' world' }

parallel.all( a, b ) // or thread.parallel( a, b )
.then(x -> console.log(x))

Will output ' worldhello' or 'hello world' like any multithread platform will.



Leo Dutraon Facebook and LinkedIn

2016-11-02 12:39 GMT-02:00 Leo Dutra <[hidden email]>:
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 Erlang/Rust/Haskell).

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 Dutraon Facebook and LinkedIn

2016-11-02 12:27 GMT-02:00 Bradley Meck <[hidden email]>:
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 <[hidden email]> 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 Dutraon Facebook and LinkedIn

2016-11-02 11:57 GMT-02:00 Bradley Meck <[hidden email]>:
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/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 : 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 <[hidden email]> 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 Dutraon Facebook and LinkedIn

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss








_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Florian Bösch
In reply to this post by Bradley Meck
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):

scheduler.spawn(function(){
  a.text = xhr();
});
scheduler.spawn(function(){
  a.text += xhr();
});

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

Promises:

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

async/await

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

Co-routines:

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 implementaiton.

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 <[hidden email]> 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 <[hidden email]> 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 Dutraon Facebook and LinkedIn

2016-11-02 11:57 GMT-02:00 Bradley Meck <[hidden email]>:
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/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 : 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 <[hidden email]> 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 Dutraon Facebook and LinkedIn

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss





_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Leo Dutra
In reply to this post by Michał Wadas
Message passing between two objects is a Law of Nature, broad and powerful.
But there's more than just workers and process spawn in life.

As I said... JS has mutable objects by default. The memory space SHALL be the same.

Atomic could handle the racing when needed and a Mutex for locking.

What is not being covered? Let it come to the surface.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Bradley Meck

> As I said... JS has mutable objects by default. The memory space SHALL be the same.

What is not being covered? Let it come to the surface.

As stated, that single threaded access to objects and shared memory multi-threaded access are very different.

On Wed, Nov 2, 2016 at 9:56 AM, Leo Dutra <[hidden email]> wrote:
Message passing between two objects is a Law of Nature, broad and powerful.
But there's more than just workers and process spawn in life.

As I said... JS has mutable objects by default. The memory space SHALL be the same.

Atomic could handle the racing when needed and a Mutex for locking.

What is not being covered? Let it come to the surface.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Leo Dutra
In reply to this post by Florian Bösch
Bösch, this is the legacy of callbacks.

ECMA does a great job with specs, but JS does every step to solve the last step.

Callback became a promise for modularity. Promise is hidden in async await for simplicity. Common constructs, but in JS they came in being adapted for JS world.

As I said, immutability is not strong in JS as it is not a PURE functional programming language.

Weird or not, this led us to the possibility of multithreading with total share and mutability.

If we wanna multithread in here, we have to respect all the JavaScript legacy. And the JavaScript legacy hurts Java/C#/whatever feelings cause IT IS DIFFERENT.

As said in my first argumentation, we have race condition problems and total share of scope and none died because of it. Multithread can be used to run these callbacks, functions and promises seamlessly and if we want it different... that's a huge bad conversation about foundations of JavaScript and a total change that would wreck the JS world and let us to anything that is not JS.

We have to decide if we stick with scope sharing and mutability or look for another language. JS is what it is.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Leo Dutra
In reply to this post by Bradley Meck
​Bradley, JIT can take care of it. If too hard... "volatile" reserved word is around since the early 00's.​



Leo Dutraon Facebook and LinkedIn

2016-11-02 13:03 GMT-02:00 Bradley Meck <[hidden email]>:

> As I said... JS has mutable objects by default. The memory space SHALL be the same.

What is not being covered? Let it come to the surface.

As stated, that single threaded access to objects and shared memory multi-threaded access are very different.

On Wed, Nov 2, 2016 at 9:56 AM, Leo Dutra <[hidden email]> wrote:
Message passing between two objects is a Law of Nature, broad and powerful.
But there's more than just workers and process spawn in life.

As I said... JS has mutable objects by default. The memory space SHALL be the same.

Atomic could handle the racing when needed and a Mutex for locking.

What is not being covered? Let it come to the surface.



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Florian Bösch
In reply to this post by Leo Dutra
What I meant to illustrate is that concurrency always leads to race conditions, and that neither promises nor async/await are free of them, and so it's silly to argue against co-routines on that basis, because of all the continuation mechanisms, they're the most convenient to use with the least drawbacks (no infectiveness).

On Wed, Nov 2, 2016 at 4:08 PM, Leo Dutra <[hidden email]> wrote:
Bösch, this is the legacy of callbacks.

ECMA does a great job with specs, but JS does every step to solve the last step.

Callback became a promise for modularity. Promise is hidden in async await for simplicity. Common constructs, but in JS they came in being adapted for JS world.

As I said, immutability is not strong in JS as it is not a PURE functional programming language.

Weird or not, this led us to the possibility of multithreading with total share and mutability.

If we wanna multithread in here, we have to respect all the JavaScript legacy. And the JavaScript legacy hurts Java/C#/whatever feelings cause IT IS DIFFERENT.

As said in my first argumentation, we have race condition problems and total share of scope and none died because of it. Multithread can be used to run these callbacks, functions and promises seamlessly and if we want it different... that's a huge bad conversation about foundations of JavaScript and a total change that would wreck the JS world and let us to anything that is not JS.

We have to decide if we stick with scope sharing and mutability or look for another language. JS is what it is.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Bradley Meck
In reply to this post by Leo Dutra
Note: this is not an implementation issue, this is a shared access introducing bugs issue.

On Wed, Nov 2, 2016 at 10:10 AM, Leo Dutra <[hidden email]> wrote:
​Bradley, JIT can take care of it. If too hard... "volatile" reserved word is around since the early 00's.​



Leo Dutraon Facebook and LinkedIn

2016-11-02 13:03 GMT-02:00 Bradley Meck <[hidden email]>:

> As I said... JS has mutable objects by default. The memory space SHALL be the same.

What is not being covered? Let it come to the surface.

As stated, that single threaded access to objects and shared memory multi-threaded access are very different.

On Wed, Nov 2, 2016 at 9:56 AM, Leo Dutra <[hidden email]> wrote:
Message passing between two objects is a Law of Nature, broad and powerful.
But there's more than just workers and process spawn in life.

As I said... JS has mutable objects by default. The memory space SHALL be the same.

Atomic could handle the racing when needed and a Mutex for locking.

What is not being covered? Let it come to the surface.




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Bradley Meck
In reply to this post by Florian Bösch
Florian, one of the great aspects of generators and async functions in ECMAScript is that they are explicit. It makes understanding where synchronization might need to occur very easy to find. I am unsure what your proposal to prevent infection as you call it would look like if it is explicit.

On Wed, Nov 2, 2016 at 10:11 AM, Florian Bösch <[hidden email]> wrote:
What I meant to illustrate is that concurrency always leads to race conditions, and that neither promises nor async/await are free of them, and so it's silly to argue against co-routines on that basis, because of all the continuation mechanisms, they're the most convenient to use with the least drawbacks (no infectiveness).

On Wed, Nov 2, 2016 at 4:08 PM, Leo Dutra <[hidden email]> wrote:
Bösch, this is the legacy of callbacks.

ECMA does a great job with specs, but JS does every step to solve the last step.

Callback became a promise for modularity. Promise is hidden in async await for simplicity. Common constructs, but in JS they came in being adapted for JS world.

As I said, immutability is not strong in JS as it is not a PURE functional programming language.

Weird or not, this led us to the possibility of multithreading with total share and mutability.

If we wanna multithread in here, we have to respect all the JavaScript legacy. And the JavaScript legacy hurts Java/C#/whatever feelings cause IT IS DIFFERENT.

As said in my first argumentation, we have race condition problems and total share of scope and none died because of it. Multithread can be used to run these callbacks, functions and promises seamlessly and if we want it different... that's a huge bad conversation about foundations of JavaScript and a total change that would wreck the JS world and let us to anything that is not JS.

We have to decide if we stick with scope sharing and mutability or look for another language. JS is what it is.



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Michał Wadas
In reply to this post by Leo Dutra
Why do you need it to be faster? Actual processing of hundreds items is fast enough on PC (under 16ms) and very likely to be fast enough on mobile. If you are writing game probably the better choice would be to go with raw numbers and/or compiled language than deal with performance hit and racing conditions in whole codebase. Because libraries are not guaranteed to be thread-safe when accessed. Even basic language spec isn't designed to be thread-safe.

Multithreading in manage language with virtual machine requires constant guards. It's not a C - changing object shape in middle of another operation is likely to cause a trouble. Even simple `foo.bar = 42` requires following steps for [[Set]] operations and these steps are not thread-safe.

On Wed, Nov 2, 2016 at 3:46 PM, Leo Dutra <[hidden email]> wrote:
This is not only easier, this is faster.

We have a single memory allocation and all the threads share it.
Considering your case:

let a = {};

async alpha() { a.text += 'hello' }
async beta() { a.text + ' world' }

parallel.all( a, b ) // or thread.parallel( a, b )
.then(x -> console.log(x))

Will output ' worldhello' or 'hello world' like any multithread platform will.



Leo Dutraon Facebook and LinkedIn

2016-11-02 12:39 GMT-02:00 Leo Dutra <[hidden email]>:
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 Erlang/Rust/Haskell).

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 Dutraon Facebook and LinkedIn

2016-11-02 12:27 GMT-02:00 Bradley Meck <[hidden email]>:
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 <[hidden email]> 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 Dutraon Facebook and LinkedIn

2016-11-02 11:57 GMT-02:00 Bradley Meck <[hidden email]>:
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/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 : 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 <[hidden email]> 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 Dutraon Facebook and LinkedIn

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss







_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal of Multithread JavaScript

Michael J. Ryan
In reply to this post by Bradley Meck

Given how many bugs I've dealt with involving race conditions in .Net, I would really rather have a solid worker pattern over any internal threading inside the main event loop in js as this thread has proposed...

Adding an rpc-like promise callback in addition to, or over message passing would be far safer...

Internal threading may be "a solved problem" but it creates so many new ones with really weird bugs to go with them.


On Nov 2, 2016 8:03 AM, "Bradley Meck" <[hidden email]> wrote:

> As I said... JS has mutable objects by default. The memory space SHALL be the same.

What is not being covered? Let it come to the surface.

As stated, that single threaded access to objects and shared memory multi-threaded access are very different.

On Wed, Nov 2, 2016 at 9:56 AM, Leo Dutra <[hidden email]> wrote:
Message passing between two objects is a Law of Nature, broad and powerful.
But there's more than just workers and process spawn in life.

As I said... JS has mutable objects by default. The memory space SHALL be the same.

Atomic could handle the racing when needed and a Mutex for locking.

What is not being covered? Let it come to the surface.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
1234
Loading...