3 ms·

Going multiprocess and using IPC doesn't intrinsically eliminate any of the tricky concurrency challenges with multi-threading. Neither do coroutines (goroutine

by nly 13y ago

Going multiprocess and using IPC doesn't intrinsically eliminate any of the tricky concurrency challenges with multi-threading. Neither do coroutines (goroutines). When you have multiple processes talking to another then, unless all your RPCs are completely stateless, you still need to orchestrate synchronisation in some form. There's also the problem that in 2013 we still don't really know how to do IPC/RPCs really well, and doing so portably is hard (Notice Mozilla are writing their own from scratch) It's all very well new languages coming along and solving the trivial stuff (setting up message queues, isolating memory) but very few of them do anything to solve the real problems.

pjmlp 13y ago
True, but it does help making the applications more resilient specially if they are stateless. The "let it crash" model from Erlang and micro-kernels. Still you are right, we are far from having an acceptable solution that we could apply everywhere, so to say.
pcwalton 13y ago
> It's all very well new languages coming along and solving the trivial stuff (setting up message queues, isolating memory) but very few of them do anything to solve the real problems. I think that Rust makes a lot of effort to move things in the right direction. In Rust you can share memory, but unless you are in the unsafe sublanguage (which is clearly marked) the type system restricts you to one of: (1) copying messages; (2) transferring ownership of a message so that the original thread cannot race on it; (3) sharing immutable memory only; (4) taking a lock before accessing mutable data. We've seen huge engineering benefits from this: making parts of Servo thread-safe has been simply a matter of running the compiler repeatedly and letting the error messages tell us where to insert the locks; when it compiles we know the data races are gone. (You can still deadlock though.)

by nly 13y ago

pjmlp 13y ago

True, but it does help making the applications more resilient specially if they are stateless. The "let it crash" model from Erlang and micro-kernels. Still you are right, we are far from having an acceptable solution that we could apply everywhere, so to say.

pcwalton 13y ago

> It's all very well new languages coming along and solving the trivial stuff (setting up message queues, isolating memory) but very few of them do anything to solve the real problems. I think that Rust makes a lot of effort to move things in the right direction. In Rust you can share memory, but unless you are in the unsafe sublanguage (which is clearly marked) the type system restricts you to one of: (1) copying messages; (2) transferring ownership of a message so that the original thread cannot race on it; (3) sharing immutable memory only; (4) taking a lock before accessing mutable data. We've seen huge engineering benefits from this: making parts of Servo thread-safe has been simply a matter of running the compiler repeatedly and letting the error messages tell us where to insert the locks; when it compiles we know the data races are gone. (You can still deadlock though.)