3 ms·
Sure but 1 and 2 end up being the same. Because when you reach the limits you clone. The thing with parallelism is not reading. It is writing. So the best way
by di4na 10y ago
Sure but 1 and 2 end up being the same. Because when you reach the limits you clone.
The thing with parallelism is not reading. It is writing. So the best way ... is to have isolated computation then reconnect them at the end... and yes it is hard..
But parallelism has few interest in my view. Concurrency is far more interested.
- catnaroek 10y ago> Sure but 1 and 2 end up being the same. Because when you reach the limits you clone. You mean (0) and (1)? Yes, deep inside, they're the one and the same. (2) is qualitatively different from the other two. > So the best way ... is to have isolated computation then reconnect them at the end... What I'm saying is that Erlang-style complete process isolation is too heavy-handed and imposes unacceptable overhead in many cases. It's better to have fine-grained control over what you isolate and what you share, as in Rust. > and yes it is hard.. It isn't easy, but rejecting large classes of errors automatically helps. > But parallelism has few interest in my view. Concurrency is far more interested. Besides writing correct programs in the face of shared resource usage, another of the main points to concurrency control is to safely parallelize the parts of your program that don't compete with each other for resources.