4 ms·

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

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

akmittal 9y ago
I think eventloop implements concurrency only but thread will implement concurrency with parallelism.
- rmrfrmrf 9y ago
  I edited my comment to clarify (hopefully). What I was thinking was that a theoretical "task pool" would execute callbacks with maximum parallelism.
STRML 9y ago
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.
- pitaj 9y ago
  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.
  - STRML 9y ago
    It depends. It could be very useful for React/React Native, for one.
- rmrfrmrf 9y ago
  If you're that concerned about performance, though, aren't doing things like `.asyncJoin()` just going to eat up any potential gains by 1) wrapping the result in a Promise and 2) throwing the Promise back into the event/microtask queue? It seems like the transport would quickly become the bottleneck. I'm also struggling to understand what tier of performance you're aiming for, since you're hoping to boost performance by using a Thread in JS when, in node, you can already code expensive computation in C++ and expose a binding back to JS (which to me makes more sense in the context of game design since that's basically what most already do with Lua--this would just be in reverse).
  - lylepstein 9y ago
    Joins like that wouldn't really be used for coordinating between multiple threads in a fine-grained fashion. For example, maybe you'd kick off two worker thread from your main thread, and each of those is going to do some fine-grained processing on some shared set of data. The main thread needs to know when that process is finished, so it joins both threads.

akmittal 9y ago

I think eventloop implements concurrency only but thread will implement concurrency with parallelism.

rmrfrmrf 9y ago
I edited my comment to clarify (hopefully). What I was thinking was that a theoretical "task pool" would execute callbacks with maximum parallelism.

STRML 9y ago

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.

pitaj 9y ago
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.
- STRML 9y ago
  It depends. It could be very useful for React/React Native, for one.
rmrfrmrf 9y ago
If you're that concerned about performance, though, aren't doing things like `.asyncJoin()` just going to eat up any potential gains by 1) wrapping the result in a Promise and 2) throwing the Promise back into the event/microtask queue? It seems like the transport would quickly become the bottleneck. I'm also struggling to understand what tier of performance you're aiming for, since you're hoping to boost performance by using a Thread in JS when, in node, you can already code expensive computation in C++ and expose a binding back to JS (which to me makes more sense in the context of game design since that's basically what most already do with Lua--this would just be in reverse).
- lylepstein 9y ago
  Joins like that wouldn't really be used for coordinating between multiple threads in a fine-grained fashion. For example, maybe you'd kick off two worker thread from your main thread, and each of those is going to do some fine-grained processing on some shared set of data. The main thread needs to know when that process is finished, so it joins both threads.