Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Concurrent JavaScript: It can work

webkit.org

Post reply on HN
Print view View original

11–20 of 189 posts

Re: Concurrent JavaScript: It can work

#11

Post by phailhaus »

spankalee wrote: post #9
amelius wrote: post #4

Earlier quoted context omitted.

Sorry, but we need shared memory for fast sharing of large immutable data structures.

Then add immutable objects to JS, which enable a host of other optimizations and are useful in single-threaded contexts too. Shared-memory multithreading is just very difficult to use correctly. Actor-style concurrency hasn't really caught on (possibly because of the poor performance of workers and postMessage), but there is probably a middle ground that's easier for developers to get right.

JS already supports immutable objects, by using Object.freeze().

Re: Concurrent JavaScript: It can work

#12

Post by spankalee »

Jtsummers wrote: post #8
amelius wrote: post #4

Earlier quoted context omitted.

Sorry, but we need shared memory for fast sharing of large immutable data structures.

Shared memory could be hidden from the users. Passing objects would really be passing control of objects. If process A creates object a, and passes it to process B, no copying has to happen if the underlying mechanism uses shared memory and access control to effect the transfer (a change of owner).

Yes. Presumably transferrable objects would have to be created on a shared heap. Non-transferrables would live on thread-local heaps.

Re: Concurrent JavaScript: It can work

#13

Post by spankalee »

phailhaus wrote: post #11
spankalee wrote: post #9

Earlier quoted context omitted.

Then add immutable objects to JS, which enable a host of other optimizations and are useful in single-threaded contexts too. Shared-memory multithreading is just very difficult to use correctly. Actor-style concurrency hasn't really caught on (possibly because of the poor performance of workers and postMessage), but there is probably a middle ground that's easier for developers to get right.

JS already supports immutable objects, by using Object.freeze().

That's not deeply immutable like you'd want for sharing objects across threads, or even for using in contexts like React and Redux.

Re: Concurrent JavaScript: It can work

#14

Post by kllrnohj »

spankalee wrote: post #3

It's awesome to see work on concurrency, but I'd really like to se a model that didn't involve shared memory. JavaScript on the web already has the concept of Transferrables. It'd be great to explore how user-land code could create transferrable objects and graphs of them so they could be sent between threads without threads sharing the same heap.

It'd also be nice if immutable objects could just be shared instead of copied or transferred instead of the current situation where they are copied and then made mutable.

Re: Concurrent JavaScript: It can work

#16

Post by pitaj »

STRML wrote: post #7
rmrfrmrf wrote: post #2

Forgive the ignorance, but why do we need threads when we already have the event loop? And, as a follow-up, why introduce a new concurrency model that's based on Java instead of, say, creating a concurrent "event pool" where execution order isn't guaranteed and callbacks are executed with maximum concurrency (edit: to clarify, I mean maximum parallelism)?

Event loops are great for handling work that can be handed off occasionally to worker threads (like how Node works with libuv), but are awful when doing consistent CPU-bound work, such as with games, 2D/3D visualizations, finance, and the like. SharedArrayBuffer is a nice primitive that allows multiple Threads (or WebWorkers) to work on data in parallel. The additional primitives they're proposing offer quite a bit o…

I think that kind of stuff it much more relevant in the land of WebAssembly. It certainly makes sense there, but in normal JS, I doubt the usefulness.

Re: Concurrent JavaScript: It can work

#17

Post by pizlonator »

spankalee wrote: post #3

It's awesome to see work on concurrency, but I'd really like to se a model that didn't involve shared memory. JavaScript on the web already has the concept of Transferrables. It'd be great to explore how user-land code could create transferrable objects and graphs of them so they could be sent between threads without threads sharing the same heap.

As someone who writes a lot of concurrent and parallel code, I can tell you it's easier to do it if the language is not imposing artificial constraints.

Also, most kinds of concurrency models will probably require the underlying VM to support some kind of shared memory. That's what this post is about.

Re: Concurrent JavaScript: It can work

#18

Post by pizlonator »

Animats wrote: post #10

Of course the language can be made to support it. Given the way Javascript is used, the question is whether supporting it will create a big mess. They have some good ideas. One is that variables can be marked as restricted to one thread. That should be the default. Other languages could benefit from that feature. Python, for example. If you want to get rid of the Global Interpreter Lock, knowing which variables can't…

I think it would be weird if objects were thread-restricted by default. Concurrency is most fun when it's easy for a thread to access an object it wants.

Re: Concurrent JavaScript: It can work

#19

Post by phailhaus »

spankalee wrote: post #13
phailhaus wrote: post #11

Earlier quoted context omitted.

JS already supports immutable objects, by using Object.freeze().

That's not deeply immutable like you'd want for sharing objects across threads, or even for using in contexts like React and Redux.

Not too hard to call Object.freeze() recursively to get the deep immutability you need. And of course there's ImmutableJS for other immutable data structures.

Re: Concurrent JavaScript: It can work

#20

Post by pitaj »

Animats wrote: post #10

Of course the language can be made to support it. Given the way Javascript is used, the question is whether supporting it will create a big mess. They have some good ideas. One is that variables can be marked as restricted to one thread. That should be the default. Other languages could benefit from that feature. Python, for example. If you want to get rid of the Global Interpreter Lock, knowing which variables can't…

I share your concerns about the usefulness and implementation of this concurrency strategy.

In my opinion, concurrency isn't necessary for JS. If web developers want high-performance, concurrent computing, they should push for adding concurrency to WASM.

I doubt concurrency could hurt JS, but I just don't see any reason for it that concurrent WASM doesn't fulfill.

Post reply on HN