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

Leo Dutra
​That's what I'm calling seamless multithreading.​

The only change is the spec change of JS being strictly single-threaded.
The proposal is to point aspects where JS can introduce seamless threads and become more paired with more mature platforms.

Async, Await, I'd add XHR and any other component with a callback, streams (as it is in Node.js), Promise resolutions and maybe events. 

_______________________________________________
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, show me an JS example where ownership would be important and I'll call you my guru.


_______________________________________________
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

doodad-js Admin
In reply to this post by Michael J. Ryan

I have used multi-threading in C#/VB.NET where objects are also mutable and I have been able to deal with racing conditions without any problem using language-provided features and techniques against them.

Currently, to reproduce multi-threading with Node.js, we have to spawn processes and use IPC which implies exchange protocols and communication channels. That makes more overhead and cause more troubles than real multi-threading with shared-objects in memory.

 

Really, I’m waiting too for multi-threading in JS, not just for parallelism, but for simplicity and conveniences.


_______________________________________________
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
Everything in this thread? I don't even understand how ownership is not important if there is concurrent access in JS. All existing JS code was written under the assumption that the arguments / variables that can be accessed are not going to be concurrently mutated across threads. *ALL* of it.

On Wed, Nov 2, 2016 at 11:43 AM, Leo Dutra <[hidden email]> wrote:

Bradley, show me an JS example where ownership would be important and I'll call you my guru.



_______________________________________________
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

Nop. I'm saying the opposite.

It will be mutated and it does not matter.
Imagining that last example I gave, if "B" ran in a thread... Nothing would change for the JS developer. "Seamless"... Magik.

The case you are issuing is what I called a change in foundations of JS... Making threads declared as in Java... And using volatiles. I hypothesized about it... But the effort would be huge and I won't like to see this war.

My proposal is break the single-thread dogma and let async, await, promises and components run multithreaded.

Simple, but against the a dogma.


_______________________________________________
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
Multiple threads are fine, but the "seamless" shared mutable variables are a no go on my end. As long as concurrent access to any existing single-thread assuming code is subject to ownership guards it seems fine. Workers, Atomics, SharedArrayBuffers, Transferables, etc. are places to look.

On Wed, Nov 2, 2016 at 11:56 AM, Leo Dutra <[hidden email]> wrote:

Nop. I'm saying the opposite.

It will be mutated and it does not matter.
Imagining that last example I gave, if "B" ran in a thread... Nothing would change for the JS developer. "Seamless"... Magik.

The case you are issuing is what I called a change in foundations of JS... Making threads declared as in Java... And using volatiles. I hypothesized about it... But the effort would be huge and I won't like to see this war.

My proposal is break the single-thread dogma and let async, await, promises and components run multithreaded.

Simple, but against the a dogma.



_______________________________________________
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

Again, async B example is possible and is the proposed.

Workers and SharedArrayBuffers are explicit. I'm proposing a non explicit thread under existing structures.

The only explicit I'd insert in my proposal are Atomics (for explicit racing conditions treatments).


_______________________________________________
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 Bradley Meck
On Wed, Nov 2, 2016 at 5:59 PM, Bradley Meck <[hidden email]> wrote:
Multiple threads are fine, but the "seamless" shared mutable variables are a no go on my end.
You already have concurrent threads of execution accessing shared mutable variables with either Promises or async/await. OS level threads are a particularly nasty variant of multitasking which I'd rather like JS to stay away from, but I don't see how that'd be an argument against co-routines.
 

_______________________________________________
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

Libuv and browsers use it. But no pool is exposed by API to JS.


_______________________________________________
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 Florian Bösch
You already have concurrent threads of execution accessing shared mutable variables with either Promises or async/await. OS level threads are a particularly nasty variant of multitasking which I'd rather like JS to stay away from, but I don't see how that'd be an argument against co-routines.

Yes, concurrent and explicitly cooperative. I'm fine with co-routines, just explicit ones (which we currently have via generators and async functions). Implicit ones make it hard to reason about if a variable needs to place guards prior to performing any action if actions pop the stack in order to do a co-routine pause/resume.

On Wed, Nov 2, 2016 at 12:11 PM, Florian Bösch <[hidden email]> wrote:
On Wed, Nov 2, 2016 at 5:59 PM, Bradley Meck <[hidden email]> wrote:
Multiple threads are fine, but the "seamless" shared mutable variables are a no go on my end.
You already have concurrent threads of execution accessing shared mutable variables with either Promises or async/await. OS level threads are a particularly nasty variant of multitasking which I'd rather like JS to stay away from, but I don't see how that'd be an argument against co-routines.
 


_______________________________________________
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
On Wed, Nov 2, 2016 at 6:16 PM, Bradley Meck <[hidden email]> wrote:
I'm fine with co-routines, just explicit ones (which we currently have via generators and async functions). Implicit ones make it hard to reason about if a variable needs to place guards prior to performing any action if actions pop the stack in order to do a co-routine pause/resume.
As I've illustrated, the natural tendency of explicit tagged asynchronous code combined with proper software engineering (separation of concerns, modularity, reuse, interfaces, encapsulation etc.) will be to infect most code with it, until the distinction of "explicit" becomes entirely meaningless.

_______________________________________________
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

Wes Garland
I'm still confused about what problem we are trying to solve here.

I had pthreads-style JS running in JS 1.7 many years ago (https://github.com/wesgarland/gpsee/tree/master/modules/thread), and after investing quite a lot of time in making it work, I found that it wasn't really all that useful in solving any problems I had at the time. Or since.  Mostly it was written for problems I thought I had, because I was a C developer trying to bend JS to fit old thought patterns.

Lately, I have been using messaging passing a la DOM workers when I need parallelization and find it quite useful. 

Incidentally, there is no "single thread dogma".  I don't know where you get this idea.  Running multiple threads of unrelated JS is completely supported by the existing spec and at least one of the engines.

Finally, Message Passing is not a JS problem either, IMO.  It's a host environment problem.  This is why, for example, we have DOM workers and not JS workers.  If you want workers for some other (ie non-browser) environment, just write it.  It's not hard, and it doesn't need to be part of the language.

Wes

On 2 November 2016 at 13:32, Florian Bösch <[hidden email]> wrote:
On Wed, Nov 2, 2016 at 6:16 PM, Bradley Meck <[hidden email]> wrote:
I'm fine with co-routines, just explicit ones (which we currently have via generators and async functions). Implicit ones make it hard to reason about if a variable needs to place guards prior to performing any action if actions pop the stack in order to do a co-routine pause/resume.
As I've illustrated, the natural tendency of explicit tagged asynchronous code combined with proper software engineering (separation of concerns, modularity, reuse, interfaces, encapsulation etc.) will be to infect most code with it, until the distinction of "explicit" becomes entirely meaningless.

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




--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

_______________________________________________
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

We could think in a pool of workers with dynamic code execution or propose, in JS spec, points where multithreading is recommended.

Anyway... looks like community is OK with the current state and that's more than enough.

Good to see interest, anyways.


_______________________________________________
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

Isiah Meadows-2

I've been working on another idea for parallelism that also leverage modules, but doesn't involve workers. It will enable read-only resource sharing of direct object instances across threads, using realms, a built-in concept of thread ownership, and atomicity for ensuring thread safety. It also allows for blocking calls for individual atomic access.


On Wed, Nov 2, 2016, 16:00 Leo Dutra <[hidden email]> wrote:

We could think in a pool of workers with dynamic code execution or propose, in JS spec, points where multithreading is recommended.

Anyway... looks like community is OK with the current state and that's more than enough.

Good to see interest, anyways.

_______________________________________________
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

Isiah Meadows-2

I'll post it to the list when it's ready, though.


On Wed, Nov 2, 2016, 16:27 Isiah Meadows <[hidden email]> wrote:

I've been working on another idea for parallelism that also leverage modules, but doesn't involve workers. It will enable read-only resource sharing of direct object instances across threads, using realms, a built-in concept of thread ownership, and atomicity for ensuring thread safety. It also allows for blocking calls for individual atomic access.


On Wed, Nov 2, 2016, 16:00 Leo Dutra <[hidden email]> wrote:

We could think in a pool of workers with dynamic code execution or propose, in JS spec, points where multithreading is recommended.

Anyway... looks like community is OK with the current state and that's more than enough.

Good to see interest, anyways.

_______________________________________________
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

Isiah Meadows-2
In reply to this post by Isiah Meadows-2
And yes, I've been paying attention to safety. What I'm actually going
to be using behind the scenes for the proposal is an event-driven
system to coordinate thread access and having both atomic updates and
synchronized calls by default, and this system will also work with the
event loop as well, with a basic priority system in place.

I'm still working on it, and I plan to have a gist in tandem with
this, so I don't have to have a long, detailed email to start. I just
want to see something a little lighter than just cloning *everything*
(zero copy preferable), and the ability to have high-level
manipulation of shared data without requiring SharedArrayBuffers, a
`malloc` reimplementation, and a boilerplatey abstraction on top of
everything.
-----

Isiah Meadows
[hidden email]


On Wed, Nov 2, 2016 at 8:27 PM, Michael J. Ryan <[hidden email]> wrote:

> At the module level for a parallel import, etc would be a decent point to
> support parallel execution... But checks would be needed to avoid migration
> at boundaries...
>
> I'm not opposed to parallel execution... But changing the async spec to
> allow unsafe threads is just a really bad idea...  I have also seen many
> bugs in .Net and Java code surrounding bugs and rather not see those types
> of shared/static access in JS.
>
> Having an import worker/parallel with a clean interface could be good...
>
>
> On Nov 2, 2016 1:28 PM, "Isiah Meadows" <[hidden email]> wrote:
>
> I've been working on another idea for parallelism that also leverage
> modules, but doesn't involve workers. It will enable read-only resource
> sharing of direct object instances across threads, using realms, a built-in
> concept of thread ownership, and atomicity for ensuring thread safety. It
> also allows for blocking calls for individual atomic access.
>
>
> On Wed, Nov 2, 2016, 16:00 Leo Dutra <[hidden email]> wrote:
>>
>> We could think in a pool of workers with dynamic code execution or
>> propose, in JS spec, points where multithreading is recommended.
>>
>> Anyway... looks like community is OK with the current state and that's
>> more than enough.
>>
>> Good to see interest, anyways.
>>
>> _______________________________________________
>>
>> 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
|

Re: Proposal of Multithread JavaScript

Henri Tuhola
In reply to this post by Leo Dutra
Leo Dutra wrote:
> looks like community is OK with the current state and that's more than enough.

This whole mailing list looks like it suffers from a severe case of Dunning-Kruger. Most of you people barely understand what is being discussed and deny the ideas presented because you have irrational love for the concepts that have been already presented and irrational fear of the new concepts. At worst you rationalize your actions based on the popularity rather than merits.

The green thread proposal such as this would be great. Most Javascript programs are interactive and have to run concurrently. With bit of work they wouldn't exclude each other. You could both wait for an event in thread as well as pass a callback for it.

Async/await has at least two problems.

a) Async routines are infective. The problem here is that it forces you to copy/paste otherwise well-behaving programs to make them behave concurrently.

For example, you might want to run a parser such that the callback it runs will trigger a download and wait for the completion before it proceeds.

With async/await, to do this you have to rewrite portions of the parser with async/await keywords to have it run asyncronously. With green threads you could just do it.

b) Async/await is a mini-language on top of an existing one. The problem is that it's too similar to vanilla Javascript.

You already have exceptions in form of reject/catch. Did you already have async/await iterators too?

Promises are just control flow graphs in disguise. Why would you need two when you already have proper constructs to represent control flow? These are complex concepts and excess of them is bad.


The benefits of Async/await over true concurrent model are questionable:

c) Javascript is a dynamic language lacking type annotations prior evaluation. With Async/await you insist that it becomes annotated with two variations for functions prior evaluation.

You insist you should have safety for non-atomic changes of variables in a language where the correctness is up to the user in the first place. Why should we have async/await "safety net" when we don't have types "safety net"?

-- Henri Tuhola, author of https://leverlanguage.com

_______________________________________________
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
Most of you people barely understand what is being discussed and deny the ideas presented because you have irrational love for the concepts that have been already presented and irrational fear of the new concepts. At worst you rationalize your actions based on the popularity rather than merits.

Ad hominem.

The green thread proposal such as this would be great. Most Javascript programs are interactive and have to run concurrently. With bit of work they wouldn't exclude each other. You could both wait for an event in thread as well as pass a callback for it.

Agree if done right.

The problem is that it's too similar to vanilla Javascript.

Similarity is a good thing between language constructs.

> You already have exceptions in form of reject/catch. Did you already have async/await iterators too?

Unclear why this is relevant.

> Promises are just control flow graphs in disguise. Why would you need two when you already have proper constructs to represent control flow? These are complex concepts and excess of them is bad.

JS has been run on event loops, understanding/controlling when you may yield control back to the event loop is why. Agree that too many concepts is a bad thing. Unclear how adding greenlets would alleviate this, in particular things like deferred rendering until your DOM is in a fully formed state so you don't get FOUC when interacting with *existing* code that does not expect access/invocation of arguments to yield back to thread.

You insist you should have safety for non-atomic changes of variables in a language where the correctness is up to the user in the first place. Why should we have async/await "safety net" when we don't have types "safety net"?

Adding more warts because of warts is never a compelling argument.

On Thu, Nov 3, 2016 at 10:08 AM, Henri Tuhola <[hidden email]> wrote:
Leo Dutra wrote:
> looks like community is OK with the current state and that's more than enough.

This whole mailing list looks like it suffers from a severe case of Dunning-Kruger. Most of you people barely understand what is being discussed and deny the ideas presented because you have irrational love for the concepts that have been already presented and irrational fear of the new concepts. At worst you rationalize your actions based on the popularity rather than merits.

The green thread proposal such as this would be great. Most Javascript programs are interactive and have to run concurrently. With bit of work they wouldn't exclude each other. You could both wait for an event in thread as well as pass a callback for it.

Async/await has at least two problems.

a) Async routines are infective. The problem here is that it forces you to copy/paste otherwise well-behaving programs to make them behave concurrently.

For example, you might want to run a parser such that the callback it runs will trigger a download and wait for the completion before it proceeds.

With async/await, to do this you have to rewrite portions of the parser with async/await keywords to have it run asyncronously. With green threads you could just do it.

b) Async/await is a mini-language on top of an existing one. The problem is that it's too similar to vanilla Javascript.

You already have exceptions in form of reject/catch. Did you already have async/await iterators too?

Promises are just control flow graphs in disguise. Why would you need two when you already have proper constructs to represent control flow? These are complex concepts and excess of them is bad.


The benefits of Async/await over true concurrent model are questionable:

c) Javascript is a dynamic language lacking type annotations prior evaluation. With Async/await you insist that it becomes annotated with two variations for functions prior evaluation.

You insist you should have safety for non-atomic changes of variables in a language where the correctness is up to the user in the first place. Why should we have async/await "safety net" when we don't have types "safety net"?

-- Henri Tuhola, author of https://leverlanguage.com

_______________________________________________
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

Wes Garland
In reply to this post by Isiah Meadows-2
Please do.  I have also done some work in this area.  I have also implemented asynchronous POSIX signals (fraught with peril) and fork().  Entertaining stuff.

My major problem has always been entrainment of crap from the global object.  Although it has been a few years since I looked at this (slightly before ES5 release).

Wes

On 2 November 2016 at 16:28, Isiah Meadows <[hidden email]> wrote:

I'll post it to the list when it's ready, though.


On Wed, Nov 2, 2016, 16:27 Isiah Meadows <[hidden email]> wrote:

I've been working on another idea for parallelism that also leverage modules, but doesn't involve workers. It will enable read-only resource sharing of direct object instances across threads, using realms, a built-in concept of thread ownership, and atomicity for ensuring thread safety. It also allows for blocking calls for individual atomic access.


On Wed, Nov 2, 2016, 16:00 Leo Dutra <[hidden email]> wrote:

We could think in a pool of workers with dynamic code execution or propose, in JS spec, points where multithreading is recommended.

Anyway... looks like community is OK with the current state and that's more than enough.

Good to see interest, anyways.

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



--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

_______________________________________________
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

J Decker
In reply to this post by Michał Wadas


On Wed, Nov 2, 2016 at 7:44 AM, Michał Wadas <[hidden email]> wrote:
Actually, is there any problem that can't be easily solved with message-passing for high-level structures or low-level shared memory buffers?


Yes, meshing dynamic geometries that involve a few 20k faces.   If you have a thread do the work, the overhead of srealizing the resulting buffers will kill any benefit.

But; typed arrays can be shared also.  (they are with C++ addons in node)

The biggest problem with node's lack of threads is they really need separate but equal heaps.  I heard that there's a global heap lock... that wouldn't be required except when allocating addition space for each heap.



To the general - stop treating programmers like idiots.  Give us the rope.  Let us hang ourselves.
 
_______________________________________________
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