| If you don't need to share any data between processes, sure. Otherwise, you will find yourself forced into a pattern that is: * extremely costly * hard to make portable cross-platform * hard to make secure (since data external to the process can't be trusted like shared-memory data can). * requires constantly validating, serializing, and deserializing data, wasting developer time on something irrelevant to their problem domain * adds a bunch of new failure modes due to the aforementioned plus having to worry about independent processes crashing * fails to integrate into the type system of your language (relevant for something like Rust that can track things like uniqueness / immutability for you) * cannot handle proper sharing of non-memory resources, except on a finicky case-by-case basis that is even more limited and hard to make cross-platform than the original communication (so now you need to stream events to specific "main" processes etc., which is a giant headache). * Can cause significant additional performance problems due to things like extra context switching, scheduler stupidity, etc. * Can result in huge memory bloat due to needing redundant copies of data structures and resources, even if they're not actually supposed to be different per thread. Make no mistake here, when you're not just running multiple copies of something that don't communicate with each other, "just use processes" is a massive pain in the ass and performance and productivity loss for the developers using it, as well as hurting user experience with things like memory bloat. The only reason to go multiprocess when you have threads is in order to create a security boundary for defense in depth, like the Chromium does--and even they are starting to reach the limits of how far you can push the multiprocess model before things become unusably slow / unworkable for the developers. |