We consider a server app development - heavily loaded with messing with big data streams. An app will be running on one powerful server. A server app will be developed in form of crossplatform application - working on Windows, Mac OS X and Linux.

So same code, many platforms for stand alone server architecture. We wonder what are the benefits of distributing applications not only over threads but over processes as well, for programmers and server end users?

Some people said to me that even having 48 cores, 4 process threads would be shared via OS through all cores, is that true?


A couple of advantages:

  1. Each process has a separate address space. If you run on a 32-bit OS, that can be an advantage because you can load up the server with lots of RAM and even though each process can only access 4GB each, if you've got multiple processes, then they can use up however much RAM you have available. If you're writing for 64-bit (and I would suggest you probably should be) then this is less of a concern (though still an advantage from an isolation point-of-view, where one process cannot corrupt another process's address space).
  2. Each process is isolated from the other. If one crashes, the others can continue to run. It's harder to make threads resilient because even though you might be able to recover from an exception, the process can still be in an insistent state which can be a problem for long-running processes.
  3. It will be easier to distribute your application across machines in the future. If you're already doing IPC between processes from the get-go, then doing IPC across machines is not so hard. If you're all in a single process to begin with, then it will be harder to distribute across servers if/when that becomes a requirement.

Some disadvantages:

  1. The architecture will be more complicated. Because you cannot (easily) share the address-space, then you need to come up with complicated IPC mechanisms straight away. Technically, you can share address-space, but then that wipes out advantages #1 & #3 above...
  2. You need to be able to deal with processes crashing. This is kind of a corollary to #1 (i.e. it's more complex), but if you went with a single-process model, then you can "handle" a crash by simply restarting the whole process. With multiple processes, you need to be able to handle individual processes crashing.

In terms of multi-threading performance, there is unlikely to be any difference between having multiple threads and having separate processes. Technically, context-switches between processes can be a little more expensive but these can usually be minimized anyway.

Also, as an aside, I'm not personally convinced that "high-performance" and "cross-platform" go well together in general. The architectures of the different platforms are quite different, for the most part, and what performs well on Linux is not going to perform very well on Windows (or vice-versa).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.