3 ms·
It comes at a cost, of course. You don't really have shared memory state, which is often easiest to conceptually think about. So you are just transforming the
by DannyBee 4y ago
It comes at a cost, of course.
You don't really have shared memory state, which is often easiest to conceptually think about.
So you are just transforming the problem into a data sharing problem between interpreters, which requires careful thought on both the language side for abstractions, and the consumer side to use right.
It also makes the tooling and verification much harder in practice - for example, you aren't reasoning about deadlocks in a single process anymore, but both within a single process and across any processes it communicates with.
At an abstract level, they are transformable into each other.
At a pragmatic level, well, there is a good reason you mostly see tooling for single-process multi-threaded programs :)
- girvo 4y ago> which is often easiest to conceptually think about Absolutely, but is also the easiest to shoot yourself in the foot with. Trade-offs! I'm biased though, I'm a big fan of deep-copy channels (which for small shallow objects is still fast), though not having the option at all for shared memory here will be a bit of a pain for certain things of course.