Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

Florian Bösch
On Wed, Nov 2, 2016 at 4:13 PM, Bradley Meck <[hidden email]> wrote:
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.

The theory that await/async are explicit is nice, but flawed, and here's why.

If you have a call stack of say A -> B -> C -> D, and you change D to async D, you have a problem. C isn't awaiting D, so it needs to do C await -> async D, but now C isn't async and B isn't awaiting C, and so forth. So you'll end up with an "infection": A await -> async B await -> async C await -> async D.

The infection spreads from down the call-stack upwards, and in doing so, it spreads sideways as well. If you have say a routine that calls a bunch of functions in succession:

A(); B(); C(); D(); and for some reason or other (because your lower level framework code became async) all of them now become awaitable as well, you end up with await A(); await B(); await C(); await D();

So eventually most calls end up being prefixed by await and most functions/methods end up being async, except for low-level code deep down.

It might surprise you that co-routine schedulers work exactly like that. Except without all the not needed line-noise. In fact, it could be argued that instead of liberally strewing await/async randomly through your code, you could simply do a preprocessor that converts every call to an await and every closure to an async, that way at least you don't need to type it out everytime. Of course you'd also get functionally true co-routines via a fairly mindless application of preprocessing.

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

Re: Proposal of Multithread JavaScript

Leo Dutra
In reply to this post by Michał Wadas
Is not a matter of being faster. Is a matter of using machine potential and using better internal instructions. 
JavaScript sits over libuv and engines with multithreading without using multithreading.

And about being faster, any serious language has a simple feature like threads and Visual Basic should not emerge even in Microsoft specs discussions. What comes next? PHP?

I still don't understand why you talk so much about racing conditions in a language which one of the main aspects is loose clojuring and racing condition.

Who cares about thread-safety if it were never expected and if it all can be seamless. And where it would not be explicit?




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

Re: Proposal of Multithread JavaScript

Michael J. Ryan

There is a difference between thread safety and unexpected event ordering in a higher level language..  just because you don't think of it in the language doesn't mean it isn't there... Also the js environments are multi threaded, it's just those threads are for internals and abstracted away from you in a safe way.


On Nov 2, 2016 8:26 AM, "Leo Dutra" <[hidden email]> wrote:
Is not a matter of being faster. Is a matter of using machine potential and using better internal instructions. 
JavaScript sits over libuv and engines with multithreading without using multithreading.

And about being faster, any serious language has a simple feature like threads and Visual Basic should not emerge even in Microsoft specs discussions. What comes next? PHP?

I still don't understand why you talk so much about racing conditions in a language which one of the main aspects is loose clojuring and racing condition.

Who cares about thread-safety if it were never expected and if it all can be seamless. And where it would not be explicit?




_______________________________________________
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
|

Re: Proposal of Multithread JavaScript

Michael J. Ryan

Sorry for reply...

var a = {};
Thread 1: Object.assign(a, {...});
Thread 2: Object.assign(a, {...});

So many places to blow up internally it isn't funny... Also, as I said, even where threading is first class with locking, there are really weird bugs when people who don't intimately understand things write code...

Having a clear worker pattern is safer...  Adding internalized immutables to improve message passing would be nice, as would an rpc to promise interface...

Real threads however is a truly bad idea in JS...


On Nov 2, 2016 8:31 AM, "Michael J. Ryan" <[hidden email]> wrote:

There is a difference between thread safety and unexpected event ordering in a higher level language..  just because you don't think of it in the language doesn't mean it isn't there... Also the js environments are multi threaded, it's just those threads are for internals and abstracted away from you in a safe way.


On Nov 2, 2016 8:26 AM, "Leo Dutra" <[hidden email]> wrote:
Is not a matter of being faster. Is a matter of using machine potential and using better internal instructions. 
JavaScript sits over libuv and engines with multithreading without using multithreading.

And about being faster, any serious language has a simple feature like threads and Visual Basic should not emerge even in Microsoft specs discussions. What comes next? PHP?

I still don't understand why you talk so much about racing conditions in a language which one of the main aspects is loose clojuring and racing condition.

Who cares about thread-safety if it were never expected and if it all can be seamless. And where it would not be explicit?




_______________________________________________
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
|

Re: Proposal of Multithread JavaScript

Leo Dutra
In reply to this post by Florian Bösch
Bösch... run, change your name and hide in the mountains or they will burn all this heresy.

There is a difference between thread safety and unexpected event ordering in a higher level language..  just because you don't think of it in the language doesn't mean it isn't there... Also the js environments are multi threaded, it's just those threads are for internals and abstracted away from you in a safe way.

Sure. The same safe way we can multithread async and await as I said in the first statements. That's what I'm calling seamless.

XHR does it and is seamless (natively it has to be a thread).

That's why all the bragging about racing condition applies as much to this multithreading as to current callbacks, promises, asyncs and awaits...

If you will fight against it... fight in the foundations. I'm proposing us to keep the flow.

Every async would be run in a thread from a pool. Chained or not, infectious or not, sharing variables or not... is an internal change I'm proposing here.

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

Re: Proposal of Multithread JavaScript

Florian Bösch
In reply to this post by Florian Bösch
There's a fairly good implementation of co-routines called greenlets for python. It depends on a few basic API calls, these are:
  1. g = greenlet.greenlet(fun) // makes a new greenlet pointing to the given function
  2. g.switch(args) // switches to that function
  3. g.switch(value) // once started delivers value inside that functions switch call
  4. g.throw(error) // raises an exception into the function
  5. greenlet.getcurrent() // returns the currently running greenlet
With these API primitives, you can implement any flavor of asynchronous/concurrent scheduler on top if you wish to do so.

On Wed, Nov 2, 2016 at 4:25 PM, Florian Bösch <[hidden email]> wrote:
On Wed, Nov 2, 2016 at 4:13 PM, Bradley Meck <[hidden email]> wrote:
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.

The theory that await/async are explicit is nice, but flawed, and here's why.

If you have a call stack of say A -> B -> C -> D, and you change D to async D, you have a problem. C isn't awaiting D, so it needs to do C await -> async D, but now C isn't async and B isn't awaiting C, and so forth. So you'll end up with an "infection": A await -> async B await -> async C await -> async D.

The infection spreads from down the call-stack upwards, and in doing so, it spreads sideways as well. If you have say a routine that calls a bunch of functions in succession:

A(); B(); C(); D(); and for some reason or other (because your lower level framework code became async) all of them now become awaitable as well, you end up with await A(); await B(); await C(); await D();

So eventually most calls end up being prefixed by await and most functions/methods end up being async, except for low-level code deep down.

It might surprise you that co-routine schedulers work exactly like that. Except without all the not needed line-noise. In fact, it could be argued that instead of liberally strewing await/async randomly through your code, you could simply do a preprocessor that converts every call to an await and every closure to an async, that way at least you don't need to type it out everytime. Of course you'd also get functionally true co-routines via a fairly mindless application of preprocessing.


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

Re: Proposal of Multithread JavaScript

Bradley Meck
In reply to this post by Leo Dutra
>  XHR does it and is seamless (natively it has to be a thread).

XHR is very different since it does not attempt to change state between threads in a racey fashion.

On Wed, Nov 2, 2016 at 10:37 AM, Leo Dutra <[hidden email]> wrote:
Bösch... run, change your name and hide in the mountains or they will burn all this heresy.

There is a difference between thread safety and unexpected event ordering in a higher level language..  just because you don't think of it in the language doesn't mean it isn't there... Also the js environments are multi threaded, it's just those threads are for internals and abstracted away from you in a safe way.

Sure. The same safe way we can multithread async and await as I said in the first statements. That's what I'm calling seamless.

XHR does it and is seamless (natively it has to be a thread).

That's why all the bragging about racing condition applies as much to this multithreading as to current callbacks, promises, asyncs and awaits...

If you will fight against it... fight in the foundations. I'm proposing us to keep the flow.

Every async would be run in a thread from a pool. Chained or not, infectious or not, sharing variables or not... is an internal change I'm proposing here.


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

Re: Proposal of Multithread JavaScript

Leo Dutra
In reply to this post by Michael J. Ryan
In JS, if you assign a string to a var containing an object... it will become an object.

Michael, I'm sorry to say JavaScript is not "safe". Try Java/Haskell/Fortran.

JavaScript is the land of pragmatic algorithms and "for internals and abstracted away from you in a safe way".

Workers are cool. I like it.

But for those who knows internals, it is very very expensive. And messaging with one worker is easy peasy. Try with 5. That amazing onmessages everywhere without a good organization and you will reclaim your Visual Studio in no time.

I'm talking about do a single

async rasterizeTheWholeGameStuff() {}

And all the stuff, as a simple async or callback, run inside a green thread.

Is that really so much? I don't think so. 
I think all of your statements against it, till now, are not considering about being "seamless".

Bösch, I think greenlets is a great example... but I'd take it in a second step, thinking about that additionals I put above.

They can't even agree with an existing, full of racing condition and no atomicity clojured function body, to be run SEAMLESS in another thread.

Maybe if I create an e-mail like [hidden email] or [hidden email]...

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

Re: Proposal of Multithread JavaScript

Bradley Meck
You will need to convince people that their problems with your proposal are solvable and not dismiss them, not state that your idea has uses. I completely agree it has uses, but the problems vastly outweigh any use case in my mind.

On Wed, Nov 2, 2016 at 10:52 AM, Leo Dutra <[hidden email]> wrote:
In JS, if you assign a string to a var containing an object... it will become an object.

Michael, I'm sorry to say JavaScript is not "safe". Try Java/Haskell/Fortran.

JavaScript is the land of pragmatic algorithms and "for internals and abstracted away from you in a safe way".

Workers are cool. I like it.

But for those who knows internals, it is very very expensive. And messaging with one worker is easy peasy. Try with 5. That amazing onmessages everywhere without a good organization and you will reclaim your Visual Studio in no time.

I'm talking about do a single

async rasterizeTheWholeGameStuff() {}

And all the stuff, as a simple async or callback, run inside a green thread.

Is that really so much? I don't think so. 
I think all of your statements against it, till now, are not considering about being "seamless".

Bösch, I think greenlets is a great example... but I'd take it in a second step, thinking about that additionals I put above.

They can't even agree with an existing, full of racing condition and no atomicity clojured function body, to be run SEAMLESS in another thread.

Maybe if I create an e-mail like [hidden email] or [hidden email]...

_______________________________________________
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
|

Re: Proposal of Multithread JavaScript

Leo Dutra
In reply to this post by Leo Dutra
> XHR is very different since it does not attempt to change state between threads in a racey fashion.

Are you sure? It changes DOM all the time, people does it in almost every callback.

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

Re: Proposal of Multithread JavaScript

Bradley Meck
> > XHR is very different since it does not attempt to change state between threads in a racey fashion.

> Are you sure? It changes DOM all the time, people does it in almost every callback.

Racey here refers to implicit/preemption. See the following example which blocks the browser permanently:

```
xhr=new XMLHttpRequest;
xhr.open('GET', 'https://cors-test.appspot.com/test');
xhr.send();
while (xhr.readyState !== 4) {}
```

On Wed, Nov 2, 2016 at 10:57 AM, Leo Dutra <[hidden email]> wrote:
> XHR is very different since it does not attempt to change state between threads in a racey fashion.

Are you sure? It changes DOM all the time, people does it in almost every callback.

_______________________________________________
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
|

Re: Proposal of Multithread JavaScript

Leo Dutra
In reply to this post by Bradley Meck
​The problems you are seeing are not in my idea. They are JavaScript problems I don't want to solve and shall not solve to have what I propose.

The only change for those using async await and promises would be changing platform version.

Internally, these things would be just moved from Event Loop for a thread and you would not notice.

I've additionally started a proposition for explicit calls, but that is an extra and not the core objective.​

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

Re: Proposal of Multithread JavaScript

Leo Dutra
In reply to this post by Bradley Meck
Michael... Object.freeze().

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

Re: Proposal of Multithread JavaScript

Leo Dutra
​Bradley, understood.

And what in this algorithm would prevent it from being run in another thread with this same seamless code?​


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

Re: Proposal of Multithread JavaScript

Bradley Meck
I assert that it cannot be seamless in JS due to the high level of mutability. Workers seem more viable. Having workers be first class and using something like ownership in rust might be possible, but shared mutable heap is not safe without very fine grained and complete transfer of ownership (this most likely would not work if things prototypes/getters/setters survive transfer).

On Wed, Nov 2, 2016 at 11:04 AM, Leo Dutra <[hidden email]> wrote:
​Bradley, understood.

And what in this algorithm would prevent it from being run in another thread with this same seamless code?​



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

Re: Proposal of Multithread JavaScript

Leo Dutra
In reply to this post by Leo Dutra
there are additional checks for scoping to prevent escape from isolation that would be needed as well.. not to mention being able to call other functions, similarly isolated - Michael

Yes. Expected. And where is the problem? You already have async await inside async await. What would change?
You already share variables and all the outer scope stuff. 

There's not a problem with frozen object in workers. But the proposal is for multithreading, very different from worker. A worker could be run in a process for workers, as it happens in some implementations. A thread is a thread. Is directly connected with the process idea originated from POSIX. And another facade, worker requires an separate script or dynamic eval. This is not maintanance friendly.

Bradley... ownership in JavaScript? Ownership in Rust is applicable... every let in Rust, without mutation explicitation, requires ownership.
JavaScript is the total opposite.

Why would you want ownership today with multithreading if you don't have it with single thread? 

​Ex:

(function outer() {
  let a = 1;

  let b = async function() {
     a = 2
  }

  await b()
  console.log(a === 2) -> true

})()​

Where is your ownership?

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

Re: Proposal of Multithread JavaScript

Bradley Meck
Where is your ownership?

The main thread has all ownership.

On Wed, Nov 2, 2016 at 11:14 AM, Leo Dutra <[hidden email]> wrote:
there are additional checks for scoping to prevent escape from isolation that would be needed as well.. not to mention being able to call other functions, similarly isolated - Michael

Yes. Expected. And where is the problem? You already have async await inside async await. What would change?
You already share variables and all the outer scope stuff. 

There's not a problem with frozen object in workers. But the proposal is for multithreading, very different from worker. A worker could be run in a process for workers, as it happens in some implementations. A thread is a thread. Is directly connected with the process idea originated from POSIX. And another facade, worker requires an separate script or dynamic eval. This is not maintanance friendly.

Bradley... ownership in JavaScript? Ownership in Rust is applicable... every let in Rust, without mutation explicitation, requires ownership.
JavaScript is the total opposite.

Why would you want ownership today with multithreading if you don't have it with single thread? 

​Ex:

(function outer() {
  let a = 1;

  let b = async function() {
     a = 2
  }

  await b()
  console.log(a === 2) -> true

})()​

Where is your ownership?


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

Re: Proposal of Multithread JavaScript

Leo Dutra
> The main thread has all ownership.

Not explicit, not important. I changed the outer scope the same way and a will last with the outer scope the same way.

If "b" ran in a thread... what would change for the JS dev?

Nothing.

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

Re: Proposal of Multithread JavaScript

Bradley Meck
If "b" ran in a thread... what would change for the JS dev?
> Nothing

On Wed, Nov 2, 2016 at 11:23 AM, Leo Dutra <[hidden email]> wrote:
> The main thread has all ownership.

Not explicit, not important. I changed the outer scope the same way and a will last with the outer scope the same way.

If "b" ran in a thread... what would change for the JS dev?

Nothing.


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

Re: Proposal of Multithread JavaScript

Bradley Meck
Not explicit, not important.

Disagree, you cannot convince me otherwise.

If "b" ran in a thread... what would change for the JS dev?
> Nothing

Not true simply by you needing to make a proposal here.

Also for many contrived examples even with real threads; some cases would be "unchanged" since they are not racing.



On Wed, Nov 2, 2016 at 11:24 AM, Bradley Meck <[hidden email]> wrote:
If "b" ran in a thread... what would change for the JS dev?
> Nothing

On Wed, Nov 2, 2016 at 11:23 AM, Leo Dutra <[hidden email]> wrote:
> The main thread has all ownership.

Not explicit, not important. I changed the outer scope the same way and a will last with the outer scope the same way.

If "b" ran in a thread... what would change for the JS dev?

Nothing.



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