4 ms·
> Workers aren’t “true threads” they’re isolates. True threads share state. True threads in fact fight over shared state, which is the problem. I see no inhere
by ttfkam 3y ago
> Workers aren’t “true threads” they’re isolates. True threads share state. True threads in fact fight over shared state, which is the problem.
I see no inherent fighting over shared state in Rust yet it clearly supports threads. "True threads" don't "fight" over shared state; they transfer ownership, whether that be through a borrow checker or with a mutex. The "fight" generally occurs when you get ownership wrong, such as in C++ or Java.
It's a distinction without a difference to identify them as isolates. Do you have as much flexibility with JS as with other languages that support parallelism? Of course not; that wasn't the design goal and usability tradeoff for JS. However, transferring ownership of shared state between two or more actively running execution environments within the same process (which is what Workers do in JS) is what most folks would describe as threads. Isolates are in fact a subset of… threads.
All isolates are threads but not all threads are isolates.
- hinkley 3y agoRust’s main feature is pre-negotiation of all disputes. You do all of the fighting at design time. Which is a very big difference for new developers. > It's a distinction without a difference to identify them as isolates. What are you talking about? They have a distinct address space per thread. The threads can only talk to each other via messages. Which require JSON parse and stringify rounds (meaning you can’t avoid event stalls on large JSON messages) They cannot share state. Those are not threads. They’re isolates. [Edit: autocomplete gibberish]
- ttfkam 3y agoAh, I see. You're not familiar with Transferable Objects. Zero-copy transfer. No parse/stringify step. https://developer.chrome.com/blog/transferable-objects-lightning-fast/ https://developer.chrome.com/blog/transferable-objects-light...