6 ms·

Why not use multiple processes instead?

gpderetta 6y ago
for a more constructive reply than a downvote, using multiple threads allows you to post closures between executors which is a very flexible and powerful message passing model. I haven't looked deep enough into scipio, but as it is inspired on seastar I assume it allows that as well. Multiple processes works better if you have little or no sharing or communication between the threads.
- glaubercosta 6y ago
  Exactly right. Scipio doesn't support that yet, but keep in mind that when Hannibal was out there putting everyone to shame Scipio was still a child. There is already a PR to support that that I intend to merge soon. Indeed without that, you might as well use multiple processes
penberg 6y ago
Excellent question! I think VoltDB, for example, uses the same application-level data partitioning approach, but with processes instead of threads. One advantage of the "thread-per-core" approach is that it allows fast communication between shards because the underlying threads share the same address space. In contrast, processes need to use a more heavy-weight approach of inter-process communication (IPC). Of course, process-based systems will have a reliability advantage, because processes cannot easily mess with each others state.
- fulafel 6y ago
  You can still use shared memory with processes.
quietbritishjim 6y ago
To turn this question on its head, why use multiple processes? That's not just rhetorical, I don't understand why you'd ask that question. The main advantages of separate processes are (1) any global variables are not shared between them, which is sometimes what you want (like Python's GIL), and (2) there is memory protection. Neither of those seem relevant to a Rust data processing program. To actually answer your question a bit: Threads allow all the benefits of processes (except the two I just mentioned), with the added benefit of being lower overhead and allow sharing information more easily (but you can still use full-blown IPC to communicate between them if you wish).
- pjmlp 6y ago
  Not all the benefits. Threads also introduce security bugs and possible instability (one thread crash brings the whole thing down).
  - secondcoming 6y ago
    I want the whole thing to come down. To me, that's preferable to a process silently crashing. Worse still, Linux's OOM killer can kill anything it wants. This is all fine if your processes are truly independent, but if they're not then you've not really gained much by using processes.
    - gpderetta 6y ago
      processes do provide well defined boundaries that can guarantee the integrity of each component separately, so it is realistic to be able to design an application that can survive the loss of one component even in a memory unsafe language.
  - quietbritishjim 6y ago
    I didn't say "all the benefits", I said > all the benefits ... (except the two I just mentioned) One of those two exceptions was indeed memory protection.
    - pjmlp 6y ago
      Fair enough.

for a more constructive reply than a downvote, using multiple threads allows you to post closures between executors which is a very flexible and powerful message passing model. I haven't looked deep enough into scipio, but as it is inspired on seastar I assume it allows that as well. Multiple processes works better if you have little or no sharing or communication between the threads.

glaubercosta 6y ago
Exactly right. Scipio doesn't support that yet, but keep in mind that when Hannibal was out there putting everyone to shame Scipio was still a child. There is already a PR to support that that I intend to merge soon. Indeed without that, you might as well use multiple processes

penberg 6y ago

Excellent question! I think VoltDB, for example, uses the same application-level data partitioning approach, but with processes instead of threads. One advantage of the "thread-per-core" approach is that it allows fast communication between shards because the underlying threads share the same address space. In contrast, processes need to use a more heavy-weight approach of inter-process communication (IPC). Of course, process-based systems will have a reliability advantage, because processes cannot easily mess with each others state.

fulafel 6y ago
You can still use shared memory with processes.

quietbritishjim 6y ago

To turn this question on its head, why use multiple processes? That's not just rhetorical, I don't understand why you'd ask that question. The main advantages of separate processes are (1) any global variables are not shared between them, which is sometimes what you want (like Python's GIL), and (2) there is memory protection. Neither of those seem relevant to a Rust data processing program. To actually answer your question a bit: Threads allow all the benefits of processes (except the two I just mentioned), with the added benefit of being lower overhead and allow sharing information more easily (but you can still use full-blown IPC to communicate between them if you wish).

pjmlp 6y ago
Not all the benefits. Threads also introduce security bugs and possible instability (one thread crash brings the whole thing down).
- secondcoming 6y ago
  I want the whole thing to come down. To me, that's preferable to a process silently crashing. Worse still, Linux's OOM killer can kill anything it wants. This is all fine if your processes are truly independent, but if they're not then you've not really gained much by using processes.
  - gpderetta 6y ago
    processes do provide well defined boundaries that can guarantee the integrity of each component separately, so it is realistic to be able to design an application that can survive the loss of one component even in a memory unsafe language.
- quietbritishjim 6y ago
  I didn't say "all the benefits", I said > all the benefits ... (except the two I just mentioned) One of those two exceptions was indeed memory protection.
  - pjmlp 6y ago
    Fair enough.