4 ms·

With async/await and callbacks, it's as you say. I/O-based concurrency is by far the most common in JS, and I'd even go so far as say in almost any language. No

by ttfkam 3y ago

With async/await and callbacks, it's as you say. I/O-based concurrency is by far the most common in JS, and I'd even go so far as say in almost any language. Not everyone needs multiple tasks using CPU at the same time nor are all tasks easily decomposable/parallelizable. However, almost all programs need to read and write files from disk, load resources from network, or a combination of the two with queries to a database. All of these do not require threads but rather non-blocking I/O. The vast majority of programs are waiting for someone else to do work rather than doing parallelizable work itself. As an aside, JS also support true threads in the form of Worker but does so in a way that prevents deadlocks while also not using explicit locking mechanisms. You are correct that there are no low-level facilities for thread (de)prioritization. Then again, if you needed that low-level fine-grained control, you'd either not be using JS or you'd write a module in a language that does for that one narrow instance where profiling has determined it will help. A large majority of the time in any language, the naive, readable approach is sufficient. Only after profiling exactly where the hotspots are should you go spelunking.

darkclouds 3y ago
> A large majority of the time in any language, the naive, readable approach is sufficient. But it also hides an attack vector I've yet to find mentioned anywhere, in much the same way multi cores can also help hide data manipulation, compared to a single core.
hinkley 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. Isolates can transfer ownership of data, but the current primitives are just godawful. It’s like someone built a foot trebuchet out guns. I tend to think of myself as pretty damned sharp, especially about concurrency, and I would not trust myself to get that code right. I can’t think of anyone I would, and I used to know some people on the Java Concurrency committee. It’s a non-feature. So what most people do is messaging, which is pretty un-exotic RPC.
- darkclouds 3y ago
  I think this is a useful link. https://stackoverflow.com/questions/1762418/what-resources-are-shared-between-threads https://stackoverflow.com/questions/1762418/what-resources-a... But this is in the context of todays "modern operating systems", other operating systems, past and present might have different terminology and ways of working, just like the terminology used in frameworks/runtimes can differ. Half the problem with any domain of knowledge, is trying to acquire accurate knowledge in the first place.
- 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 ago
    Rust’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]
    - 3y ago

by ttfkam 3y ago

darkclouds 3y ago

> A large majority of the time in any language, the naive, readable approach is sufficient. But it also hides an attack vector I've yet to find mentioned anywhere, in much the same way multi cores can also help hide data manipulation, compared to a single core.

hinkley 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. Isolates can transfer ownership of data, but the current primitives are just godawful. It’s like someone built a foot trebuchet out guns. I tend to think of myself as pretty damned sharp, especially about concurrency, and I would not trust myself to get that code right. I can’t think of anyone I would, and I used to know some people on the Java Concurrency committee. It’s a non-feature. So what most people do is messaging, which is pretty un-exotic RPC.

darkclouds 3y ago
I think this is a useful link. https://stackoverflow.com/questions/1762418/what-resources-are-shared-between-threads https://stackoverflow.com/questions/1762418/what-resources-a... But this is in the context of todays "modern operating systems", other operating systems, past and present might have different terminology and ways of working, just like the terminology used in frameworks/runtimes can differ. Half the problem with any domain of knowledge, is trying to acquire accurate knowledge in the first place.
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 ago
  Rust’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]
  - 3y ago