Single or multiple process, what criteria decides it?

Question

In embedded systems using linux for an application; under which condition will you divide an application into two/three processes. My main doubt is; is it required to divide a single application component into multiple processes and then run multiple processes to achieve the required application functionality.

Answer 1

By experience I tend to isolate possibly problematic pieces of code. For example if you're depending on a sensor which ships with 3rd party libraries that you do not trust, making it a separate process will make your application more robust and fault-tolerant because you'll be (hopefully) able to restarts only parts of it.

Also for integration purposes it might be easier. Suppose your process A runs fine, then you can plug in the process B easily instead of adding new parts to process A. It might not seem like a big plus right now but it depends a lot on your project.

It does come with some overhead however, as dealing with synchronization and message passing can be more complicated and add to the design.

You don't have to do anything like that however.

Answer 2

You don't tell much about the circumstances that led you to your question, so I can only guess what kind of answer you are interested in.

Linux offers multi-threading functionality since ages, so concurrent programming can be done without multiple processes.

There is rarely a functional reason to divide integral components of an application into processes.

My suggestion is to write a single-process application. Should the requirement arise, that is: a problem can only be solved by managing runtime resources in separate processes, you can still take on the heavy work of solving inter-process communication and resource sharing, without having to change much in your business logic.