Re: Proposal of Multithread JavaScript

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:

Re: Proposal of Multithread JavaScript

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 m...@isiahmeadows.com On Sun, Mar 12,

Re: Proposal of Multithread JavaScript

On Sun, Mar 12, 2017 at 7:11 PM, /#!/JoePea 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.

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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,

RE: Proposal of Multithread JavaScript

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

RE: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

Inline - Isiah Meadows m...@isiahmeadows.com On Thu, Nov 3, 2016 at 10:08 PM, Leo Dutra 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

Re: Proposal of Multithread JavaScript

Inline. - Isiah Meadows m...@isiahmeadows.com On Thu, Nov 3, 2016 at 6:41 PM, Michael J. Ryan 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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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 wrote: > Workers need serialization, threads would not. > > In Node, lack of threading requires a prior spawn of a

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

Just to make sure this gets attention... Lars Hansen's Shared Memory and Atomics proposal is at stage 2: - https://github.com/tc39/ecmascript_sharedmem - https://github.com/rwaldron/tc39-notes/blob/master/es7/2016-07/jul-28.md#10iia-shared-memory-and-atomics -

Re: Proposal of Multithread JavaScript

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 wrote: > On Thu, Nov 3, 2016 at 9:10 AM, Michał Wadas > wrote: > > Why you can't solve it with shared memory buffer? Shared - I mean

Re: Proposal of Multithread JavaScript

On Thu, Nov 3, 2016 at 9:10 AM, Michał Wadas 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

Re: Proposal of Multithread JavaScript

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" wrote: > > > On Wed, Nov 2, 2016 at 7:44 AM, Michał Wadas > wrote: > >> Actually, is there any problem that can't be

Re: Proposal of Multithread JavaScript

On Wed, Nov 2, 2016 at 7:44 AM, Michał Wadas 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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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,

Re: Proposal of Multithread JavaScript

I'll post it to the list when it's ready, though. On Wed, Nov 2, 2016, 16:27 Isiah Meadows 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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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.

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

On Wed, Nov 2, 2016 at 6:16 PM, Bradley Meck 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

Re: Proposal of Multithread JavaScript

Libuv and browsers use it. But no pool is exposed by API to JS. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

On Wed, Nov 2, 2016 at 5:59 PM, Bradley Meck 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.

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

RE: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

Bradley, show me an JS example where ownership would be important and I'll call you my guru. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

> 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

Re: Proposal of Multithread JavaScript

> Where is your ownership? The main thread has all ownership. On Wed, Nov 2, 2016 at 11:14 AM, Leo Dutra 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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

​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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

Michael... Object.freeze(). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

​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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

> 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 es-discuss@mozilla.org

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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.

Re: Proposal of Multithread JavaScript

> 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 wrote: > Bösch... run, change your name and hide in the

Re: Proposal of Multithread JavaScript

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) //

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

On Wed, Nov 2, 2016 at 4:13 PM, Bradley Meck 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 >

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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 wrote: > ​Bradley, JIT can take care of it. If too hard... "volatile" reserved word > is around since the early 00's.​ > > > > *Leo Dutra,

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

​Bradley, JIT can take care of it. If too hard... "volatile" reserved word is around since the early 00's.​ *Leo Dutra, **on **Facebook **and LinkedIn * 2016-11-02 13:03 GMT-02:00 Bradley Meck : >

Re: Proposal of Multithread JavaScript

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,

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

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 Dutra, **on **Facebook **and LinkedIn *

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

​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

Re: Proposal of Multithread JavaScript

​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

Re: Proposal of Multithread JavaScript

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

Re: Proposal of Multithread JavaScript

*TL;DR:* (function foo() { ... })() // sync and single threaded (*async *function() { ... })() // async and parallel Additional: parallel.run() parallel.stream() parallel.sleep() parallel.waterfall() ... *Leo Dutra, **on **Facebook **and LinkedIn