Concurrent JavaScript: It can work
webkit.org
Concurrent JavaScript: It can work
1–10 of 189 posts
Re: Concurrent JavaScript: It can work
#2Forgive 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)?
Re: Concurrent JavaScript: It can work
#3It'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.
Re: Concurrent JavaScript: It can work
#4It'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.
Sorry, but we need shared memory for fast sharing of large immutable data structures.
Re: Concurrent JavaScript: It can work
#5Forgive 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)?
I think eventloop implements concurrency only but thread will implement concurrency with parallelism.
Re: Concurrent JavaScript: It can work
#6This is very interesting. If this is indeed implemented, it will remove a serious hurdle from the equation of RN. Still JS, but the ceiling will go up considerably.
Re: Concurrent JavaScript: It can work
#7Forgive 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 of flexibility. For one, I would really like an easy `new Thread(fn).asyncJoin()` to create a Promise to do expensive CPU-bound work. There are a few npm modules that do some version of this but it can be slow.
As for the concurrency model, it should be possible to delegate tasks to a pool in this one. Map an array of input data and functions to an array of promises, then Promise.all() or Promise.race() on them.
Re: Concurrent JavaScript: It can work
#8It'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.
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).
Re: Concurrent JavaScript: It can work
#9It'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.
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.
Re: Concurrent JavaScript: It can work
#10Of 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 be shared between threads is a big help.
Variables should be owned by a thread or owned by a lock. Rust went that way, and it works well. The proposal here is old C-style locking, where there are locks and variables, but the language doesn't know which locks are protecting which variables.