Multi-threading->multi-processing tendency

Question

Today there are much more RAM available than in old day and I see that devs are tend to go from multi-threading to multi-processing.

Here good Multi-process Architecture argumentation from Chrome devs:

In this world, browsers that put everything in one process face real challenges for robustness, responsiveness, and security. If one web app causes a crash in the rendering engine, it will take the rest of the browser with it, including any other web apps that are open. Web apps often have to compete with each other for CPU time on a single thread, sometimes causing the entire browser to become unresponsive.
Security is also a concern, because a web page that exploits a vulnerability in the rendering engine can often take over your entire computer.

So multi-processing pros:

• Isolation that will mean robustness and security. (I think we can argue about responsiveness because it is not so hard to make good responsiveness with correct multi-thread and thread pool management)

Cons:

• Memory overhead
• Greater start time

If we will speak not in browser context we will tend to put any 3d party lib in the separate process. Because we can't be sure that this lib will not crash us, hang us or will not insecure our data. There some alternative to multi-process approach like AppDomains concept in .NET. But they are unable to provide needed robustness with flexibility because it works only with managed code, not with native. I think that is true for any other software framework.

So how do you think, is the multi-process architecture at least for 3d-party libs is reasonable choice or it is evil and the result of programmers laziness, their desires to simplify to itself life?

Answer 1

It completely depends on application you write. Think about some computation engine. Having multiple processes in ambit of HPC is often very expensive and requires serious justification.

Many applications are moving towards Multicore architectures, because hardware our program suppose to run on, reaches its limits in terms of clock-speed, hence programming languages provide more and more sophisticated language artifacts to face that future. (Microsoft TPL, Intel TBB, GCC, Matlab and many others to support offload to Xeon Phi many-core coprocessors).

When you dealing with many/multi-core core architectures the crucial are data-structures and memory access patterns. You will be surprised how much performance one may get if at least those 2 parameters are correctly tailored against his program.

Having multi-process, if not completely prohibits, at least makes it really challenging to deal with things like RAM fragmentation, CPU Cache. While writing computational engine (again, just an example) you don't worry about security in a way chrome team has to worry about, you worry about points of failure, which again, much more easier to deal with, and to manage in future years, while having all in one single processes's.

Now:

So how do you think, is the multi-process architecture at least for 3d-party libs is reasonable choice or it is evil and the result of programmers laziness, their desires to simplify to itself life?

It is a thread off. The question one should ask, in the context of the question you asked, is: what should my application do, if 3rd party lib fails ? How am I going to handle it ? Answering those question will let you to make right choice for your project.

I personally, would move in another process not for failure management, but for platform/language integration challenge. Say if that is a Python/C++ project, and my host application is C# , I would prefer to avoid all that interop/marshalling and just invoke process from command line. Again, if that is possible, or sustainable.

All said is for, that what is ok for Chrome team absolutely not necessary would be ok for your next project. Actually, quite likely, a lot of that will not. So understand the reasons, learn concepts and choose what is more appropriate in your case.