Seems like a bad idea. Processes are more elegant and scalable than threads as they discourage the use of shared memory. Shared memory is often a bad idea. You

Seems like a bad idea. Processes are more elegant and scalable than threads as they discourage the use of shared memory. Shared memory is often a bad idea. You end up with different threads competing and queuing up to access or write the same data (e.g. waiting on each other to acquire a lock with mutexes - This immediately disqualifies the system from becoming embarrassingly parallel) and it becomes the OS's problem to figure out when to allow which thread to access what memory... This is bad because the OS doesn't care about optimizing memory access for your specific use case. It will treat your 'high performance' database in the same way as it treats a run-of-the-mill Gimp desktop application.... With the process model, it encourages using separate memory for each process; this forces developers to think about things like memory consistency and availability and gives them more flexibility in terms of scalability across multiple CPU cores or even hosts. Processes are far better abstractions than threads for modeling concurrent systems since their logic is fundamentally the same regardless of whether they run across different CPU cores or different hosts. > The overhead of cross-process context switches is inherently higher than switching between threads in the same process I remember researching this a while back. It depends on the specific OS and hardware. It's not so straight forward and this is something which tends to change over time and the differences are usually insignificant anyway. Also, it's important not to conflate performance with scalability - These two characteristics are orthogonal at best and oftentimes conflicting. Oftentimes, to scale horizontally, a system needs to incur a performance penalty as additional work is required to route and coordinate actions across multiple CPUs or hosts. A scalable system can service a much larger number (or even sometimes theoretically unlimited) number of requests but it will typically perform worse than a non-scalable system if you judge it on a requests-per-CPU-core basis.