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

Michał Wadas

Why you can't solve it with shared memory buffer? Shared - I mean instance of SharedArrayBuffer.


On 3 Nov 2016 5:05 p.m., "J Decker" <[hidden email]> wrote:


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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal of Multithread JavaScript

J Decker


On Thu, Nov 3, 2016 at 9:10 AM, Michał Wadas <[hidden email]> wrote:

Why you can't solve it with shared memory buffer? Shared - I mean instance of SharedArrayBuffer.


not in node; in browser ya... where webworkers are threads.  (and not in javascript base)
And while firefox is beginning to look appealing again I'm stuck on chrome (native android) 
 
On 3 Nov 2016 5:05 p.m., "J Decker" <[hidden email]> wrote:


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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal of Multithread JavaScript

Isiah Meadows-2

Chrome/V8 has it behind a flag IIRC. I forget its exact name, but I know it exists.


On Thu, Nov 3, 2016, 12:12 J Decker <[hidden email]> wrote:
On Thu, Nov 3, 2016 at 9:10 AM, Michał Wadas <[hidden email]> wrote:

Why you can't solve it with shared memory buffer? Shared - I mean instance of SharedArrayBuffer.


not in node; in browser ya... where webworkers are threads.  (and not in javascript base)
And while firefox is beginning to look appealing again I'm stuck on chrome (native android) 
 
On 3 Nov 2016 5:05 p.m., "J Decker" <[hidden email]> wrote:


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

_______________________________________________
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

Rick Waldron

On Thu, Nov 3, 2016 at 12:34 PM Isiah Meadows <[hidden email]> wrote:

Chrome/V8 has it behind a flag IIRC. I forget its exact name, but I know it exists.


On Thu, Nov 3, 2016, 12:12 J Decker <[hidden email]> wrote:
On Thu, Nov 3, 2016 at 9:10 AM, Michał Wadas <[hidden email]> wrote:

Why you can't solve it with shared memory buffer? Shared - I mean instance of SharedArrayBuffer.


not in node; in browser ya... where webworkers are threads.  (and not in javascript base)
And while firefox is beginning to look appealing again I'm stuck on chrome (native android) 
 
On 3 Nov 2016 5:05 p.m., "J Decker" <[hidden email]> wrote:


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

Workers need serialization, threads would not.

In Node, lack of threading requires a prior spawn of a bunch of native processes and manually build a tasking pool.

Web Workers spawn a specific script (if you respawn the caller you are doing dirty job).

Maybe we should fork projects like the one Isiah brought to us and headbang compiling it with the lovely gyp.

So much emotion. Much doge work. So delicious.

You could simply spawn a thread in almost the same way we use Node streams...

but I won't fight 10 guys alone.


_______________________________________________
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
Leo you can see https://github.com/nodejs/node/pull/2133 for Workers in node that use threads instead of processes.

On Thu, Nov 3, 2016 at 1:19 PM, Leo Dutra <[hidden email]> wrote:

Workers need serialization, threads would not.

In Node, lack of threading requires a prior spawn of a bunch of native processes and manually build a tasking pool.

Web Workers spawn a specific script (if you respawn the caller you are doing dirty job).

Maybe we should fork projects like the one Isiah brought to us and headbang compiling it with the lovely gyp.

So much emotion. Much doge work. So delicious.

You could simply spawn a thread in almost the same way we use Node streams...

but I won't fight 10 guys alone.


_______________________________________________
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 Leo Dutra
There is no requirement for a host environment to use any kind of serialization for worker threads.  It's completely fine to pass messages which are binary in nature.  In fact, I have  passed C structs as messages between JavaScript workers.

I don't know why you think this is a fight.  You should understand that you are proposing a very, very, very significant modification of the ES standard and you have not yet defined a problem which this work would solve.

Wes

On 3 November 2016 at 14:19, Leo Dutra <[hidden email]> wrote:

Workers need serialization, threads would not.

In Node, lack of threading requires a prior spawn of a bunch of native processes and manually build a tasking pool.

Web Workers spawn a specific script (if you respawn the caller you are doing dirty job).

Maybe we should fork projects like the one Isiah brought to us and headbang compiling it with the lovely gyp.

So much emotion. Much doge work. So delicious.

You could simply spawn a thread in almost the same way we use Node streams...

but I won't fight 10 guys alone.


_______________________________________________
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

I have defined many times, but you guys are in love with workers.

A little look in Java's Runnables would demonstrate de nature and difference I'm bringing to this thread.

Workers can't even modify DOM directly...

Very different of go routines, Java/Scala threads etc.

Workers require way more control and coding by the nature of their declaration and messaging. A worker lives and awaits... A thread is run against a living spawned process and is garbaged after the usage.


_______________________________________________
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

Workers define a clear boundary...  In Windows, only the main thread can touch the ui..  and in Linux, threads are almost as expensive as processes...

Just the same, I'm okay with threads, but feel that not having shared state I'd better as you will avoid a large amount of potential bugs.  Having clear separation still allows you to solve many problems where threading would help in a clean and clear way.

There's been other discussions of a load a threaded module, which could have a clear line in the sand.  I wouldn't even mind coroutines or a good, safe csp implementation...  However, those lines would take longer to develop safely and take longer still to lock down appropriately.

Having worked as threads and allowing a lighter weight message would negate a lot of the negatives you mention... It doesn't have to be a serialized message.  Adding an immutable object probative would do the trick (given fewer hurdles).

All ui/Dom access needs to be serialized anyway, I don't think that's a good example of why we absolutely need shared state threads.


On Nov 3, 2016 12:19 PM, "Leo Dutra" <[hidden email]> wrote:

I have defined many times, but you guys are in love with workers.

A little look in Java's Runnables would demonstrate de nature and difference I'm bringing to this thread.

Workers can't even modify DOM directly...

Very different of go routines, Java/Scala threads etc.

Workers require way more control and coding by the nature of their declaration and messaging. A worker lives and awaits... A thread is run against a living spawned process and is garbaged after the usage.


_______________________________________________
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

Why would UI/DOM access need to be serialized?

And Windows is a great reference of what not to do.  .NET as a whole too, since all before C# 6 comes from bad MS and all after is copied from somewhere. NT should be thrown away and be replaced by a sweet BSD layer
The only thing they did well are Registered I/O.

Threads are not that good in Linux because a process starup in Linux is blazing fast... And the work are not that great; except when you have a thread pool, and a process pool is quite not possible (at least I've never seen one for general application software).

Hard work is not a reason to discard a gamechanging enhancement.

There's many enterprises which prohibit devs from using threads and some other language features... They presume retard devs.

A bad developer is not JavaScript issue. A JavaScript issue is the impossibility of doing something Java, C, C#, Python, Scala, Haskell, Go and a bunch more do with a simple keyword or method.


_______________________________________________
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 Michael J. Ryan
Inline.
-----

Isiah Meadows
[hidden email]


On Thu, Nov 3, 2016 at 6:41 PM, Michael J. Ryan <[hidden email]> wrote:
> Workers define a clear boundary...  In Windows, only the main thread can
> touch the ui..  and in Linux, threads are almost as expensive as
> processes...

That's actually a symptom of Linux having significantly lighter
processes than Windows. Windows keeps the two as completely
independent concepts, and make it rough on the developer if they want
to have inter-process communication, while Linux (and many BSDs) don't
draw such a clear-cut line with processes vs threads. It comes down to
a fundamental difference in approach: Unix derivatives have always
aimed to support multi-*process* applications, while Windows aimed to
support multi-*threaded* ones. (Hence, why Node.js's
`child_process.fork` has always created new processes - it started on
Linux, and processes are almost as cheap as threads.)

>
> Just the same, I'm okay with threads, but feel that not having shared state
> I'd better as you will avoid a large amount of potential bugs.  Having clear
> separation still allows you to solve many problems where threading would
> help in a clean and clear way.
>
> There's been other discussions of a load a threaded module, which could have
> a clear line in the sand.  I wouldn't even mind coroutines or a good, safe
> csp implementation...  However, those lines would take longer to develop
> safely and take longer still to lock down appropriately.
>
> Having worked as threads and allowing a lighter weight message would negate
> a lot of the negatives you mention... It doesn't have to be a serialized
> message.  Adding an immutable object probative would do the trick (given
> fewer hurdles).
>
> All ui/Dom access needs to be serialized anyway, I don't think that's a good
> example of why we absolutely need shared state threads.

I agree that you already have to serialize stuff for the DOM to some
extent, anyways. That's how much of the API works (and it's also how
*not* to design an API).

A good case where high-level shared state would come very handy is
with virtual DOM. If you can offload the backing model to another
thread, you can keep the application even faster, since you can diff
the old DOM while recent UI changes are being processed in another
thread.

But without that ability to share those object instances in a GC-aware
manner and at high frequency, it's rather difficult to do without
generating a *lot* of garbage. As for why a `SharedArrayBuffer` is not
acceptable, it's because there's no way to grow it in place, in case
you have a very large DOM structure.

>
>
> On Nov 3, 2016 12:19 PM, "Leo Dutra" <[hidden email]> wrote:
>>
>> I have defined many times, but you guys are in love with workers.
>>
>> A little look in Java's Runnables would demonstrate de nature and
>> difference I'm bringing to this thread.
>>
>> Workers can't even modify DOM directly...
>>
>> Very different of go routines, Java/Scala threads etc.
>>
>> Workers require way more control and coding by the nature of their
>> declaration and messaging. A worker lives and awaits... A thread is run
>> against a living spawned process and is garbaged after the usage.
>>
>>
>> _______________________________________________
>> 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

Isiah Meadows-2
In reply to this post by Leo Dutra
Inline
-----

Isiah Meadows
[hidden email]


On Thu, Nov 3, 2016 at 10:08 PM, Leo Dutra <[hidden email]> wrote:
> Why would UI/DOM access need to be serialized?

It already kind of does when working in single-threaded code. How
often do you need to do things like
`element.appendChild(document.createTextNode(text))`, instead of just
`element.appendChild(text)`? How often do you need to do
`Object.assign(newElem.style, { ... })`? How often do you need to use
a loop to add an array of detached DOM elements to the live DOM?
Sounds like serialization boilerplate to me, just in single-threaded
code.

>
> And Windows is a great reference of what not to do.  .NET as a whole too,
> since all before C# 6 comes from bad MS and all after is copied from
> somewhere. NT should be thrown away and be replaced by a sweet BSD layer
> The only thing they did well are Registered I/O.
>
> Threads are not that good in Linux because a process starup in Linux is
> blazing fast... And the work are not that great; except when you have a
> thread pool, and a process pool is quite not possible (at least I've never
> seen one for general application software).

I'm guessing you're not too terribly familiar with Node's `cluster`
module? It provides several primitives for building process pools, and
is fairly simple to use. Usually, people use it directly, not with a
general process pool abstraction.

https://nodejs.org/api/cluster.html

It's more useful on the server than the client, though.

(Oh, and processes are comparatively cheap in Linux.)

>
> Hard work is not a reason to discard a gamechanging enhancement.
>
> There's many enterprises which prohibit devs from using threads and some
> other language features... They presume retard devs.
>
> A bad developer is not JavaScript issue. A JavaScript issue is the
> impossibility of doing something Java, C, C#, Python, Scala, Haskell, Go and
> a bunch more do with a simple keyword or method.
>
>
> _______________________________________________
> 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

doodad-js Admin
> I'm guessing you're not too terribly familiar with Node's `cluster` module? It provides several primitives for building process pools, and is fairly simple to use. Usually, people use it directly, not with a general process pool abstraction.
>
>https://nodejs.org/api/cluster.html
>
>It's more useful on the server than the client, though.
>
>(Oh, and processes are comparatively cheap in Linux.)

That requires IPC to exchange data between the master and slaves. And currently, IPC is implemented with JSON.stringify/JSON.parse.

Using threads and shared objects, IPC and serialization/deserialization of objects will no longer be required.

_______________________________________________
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

Isiah, the only serialization, or at least heavy one, in DOM is .innerHTML and some other textual stuff. Appending moves pointers and references in the internal DOM representations (a real problem in old browsers like IE was this representations ran in another host Engine).

Appending nodes are blazing fast... And is structural code, not evented as the bad message passing of spawned processes in Node or Web Workers.

Isiah, I'm used to cluster, maybe more than I'd like.

I'm very used to Java threads, and now on Java 8 a Runnable is a Functional interface implementation (means in Java that Runnable.run() became a simple lambda function). This is more than enough similar to what a JS function could either be on a thread API.

If Node abstracted process as a kind of Host object like a DOM Node, messaging would be lighter and probably serialization would be done at C levels, not on JS strings / stringify level.

Java Threads are part of a scope, Node clusters are not. This implies speed, scoping and control differences enough to say Workers/clustered processes are way different from what I propose.

And more, cluster process or process spawn or Web Workers require  a particular separated JS ( or you will do dirty stuff putting run JS together with massive  ignored JS).

A thread would be as simple as:

thread.run( (thrd) => console.log(thrd.id) )

A simple "callback"/ stream/ whatever you call run out of Event Loop. A while(true) would not lock any other JS operation.

That's the most powerful part of thread spawn and to allow JS devs to do it is much. This with indication for components, like XHR, to run callback in a threaded function out of Event Loop.

Event Loop should do all that Node does and People say it does good: io messaging and no aggregation / loop intensive stuff.

There's no reason to care with mutability since callbacks mutated values today and most new js devs already think it is running on a parallel process (many many people will even call you crazy if u say).

Again, think in a function as any callback today, but running out of the EL.

I can't make a more realistic metaphor.


_______________________________________________
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

Boris Zbarsky
In reply to this post by doodad-js Admin
On 11/4/16 3:16 AM, doodad-js Admin wrote:
> Using threads and shared objects, IPC and serialization/deserialization of objects will no longer be required.

Just so we're clear, what _will_ be required, in the VM, is locking
around property access and a GC that can deal with multiple threads, right?

SpiderMonkey used to have all that.  We removed it because the
performance penalties it imposed were not acceptable.  Reintroducing it
would be a pretty hard sell, for that same reason.

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

/#!/JoePea
Leo's idea that JavaScript code as it is today won't be impacted when async functions are run in separate threads is interesting. It would complicate the JS engine implementation so that locks are needed when different scopes access a variable (something which was formally easily safe due to running on a single thread and now needs to be guarded on multiple threads), but in theory, multiple threads for async functions that don't need guards against each other (detectable with more intricate scope analysis) could be an interesting performance boost.

Suppose the following async function does a cpu-intensive calculation. It would be nice to be able to do this without workers:

```js
async function somethingIntensive(input) {
  // in new thread, automatically because this function isn't touching outer scope.
  // ... some cryptographic calculation using input ...
  return result
}

// main thread)
somethingIntensive().then(result => {console.log(result)})
```

Maybe the `await`keyword didn't even have to be used inside the async function, but just having the `async` keyword makes it possible for the engine to make a thread if it determines it can do so.

This is a good idea. There's no reason an async function needs to be on the same thread if it doesn't have to be. Maybe there can be heuristics, like "hmmm, this function doesn't touch absolutely anything in the outer scope, and the `input` is a primitive non-object value so we don't even need to guard anything... let's run it in a new thread".

Or, maybe there can be a new keyword for this specifically if people want it to be explicit:

```js
thread function somethingIntense(input) {...}
```

The engine could automatically guard stuff in certain ways that would need to be spec'd out. So, in some cases, threading would be useless if the function needs to access stuff from outer scope, and the engine might even be able to *not* run the function in a separate thread if that makes guarding easier.



/#!/JoePea

On Fri, Nov 4, 2016 at 5:42 AM, Boris Zbarsky <[hidden email]> wrote:
On 11/4/16 3:16 AM, doodad-js Admin wrote:
Using threads and shared objects, IPC and serialization/deserialization of objects will no longer be required.

Just so we're clear, what _will_ be required, in the VM, is locking around property access and a GC that can deal with multiple threads, right?

SpiderMonkey used to have all that.  We removed it because the performance penalties it imposed were not acceptable.  Reintroducing it would be a pretty hard sell, for that same reason.

-Boris

_______________________________________________
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

/#!/JoePea

On Sun, Mar 12, 2017 at 7:11 PM, /#!/JoePea <[hidden email]> wrote:
Leo's idea that JavaScript code as it is today won't be impacted when async functions are run in separate threads is interesting.

​I meant, "Leo's idea that JavaScript code as it is today can work exactly the same (f.e. async functions) while behind the scenes be threaded without impacting end JS-devs is interesting."​


/#!/JoePea

_______________________________________________
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
For prior discussion on a fairly similar concept, see my proposal [1]
and related thread [2].

[1]: https://gist.github.com/isiahmeadows/a01799b4dc9019c55dfcd809450afd24
[2]: https://esdiscuss.org/topic/module-based-parallel-js-strawman
-----

Isiah Meadows
[hidden email]


On Sun, Mar 12, 2017 at 10:14 PM, /#!/JoePea <[hidden email]> wrote:

>
> On Sun, Mar 12, 2017 at 7:11 PM, /#!/JoePea <[hidden email]> wrote:
>>
>> Leo's idea that JavaScript code as it is today won't be impacted when
>> async functions are run in separate threads is interesting.
>
>
> I meant, "Leo's idea that JavaScript code as it is today can work exactly
> the same (f.e. async functions) while behind the scenes be threaded without
> impacting end JS-devs is interesting."
>
>
> /#!/JoePea
>
> _______________________________________________
> 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
If anybody wants to play with MT ES (I'm not saying I think this is a good idea) -- you might want to dig up a ~ten-year old version of Spidermonkey, perhaps the JS 1.7 release (MT "safety" broke with Array Extras).   Then add this code, which implements a basic Thread class: https://github.com/wesgarland/gpsee/blob/master/modules/thread/   (hopefully that code builds without too much effort.......I stopped using it as soon as it was finished, I did not find the paradigm useful in my work).

The result is lock-free property access (anarchy!) on a global object shared across operating system threads.

You might be able to then prototype a smarter API in ES3 and see how you like it.

I think you might also be able to try similar experiments with Rhino using Java threads.

Wes

On 13 March 2017 at 00:19, Isiah Meadows <[hidden email]> wrote:
For prior discussion on a fairly similar concept, see my proposal [1]
and related thread [2].

[1]: https://gist.github.com/isiahmeadows/a01799b4dc9019c55dfcd809450afd24
[2]: https://esdiscuss.org/topic/module-based-parallel-js-strawman
-----

Isiah Meadows
[hidden email]


On Sun, Mar 12, 2017 at 10:14 PM, /#!/JoePea <[hidden email]> wrote:
>
> On Sun, Mar 12, 2017 at 7:11 PM, /#!/JoePea <[hidden email]> wrote:
>>
>> Leo's idea that JavaScript code as it is today won't be impacted when
>> async functions are run in separate threads is interesting.
>
>
> I meant, "Leo's idea that JavaScript code as it is today can work exactly
> the same (f.e. async functions) while behind the scenes be threaded without
> impacting end JS-devs is interesting."
>
>
> /#!/JoePea
>
> _______________________________________________
> 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



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