What are some use cases for creating child processes? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 months ago.

Improve this question

I am trying to understand processes and their use in software engineering. Not processes in general but rather creating a process from within a program.
It seems a really powerfull tool and i have a feeling that it is used in some very important areas of software engineering.

Why would someone create a child process? What are the use cases for having a program that calls other programs? Are there any design patterns that specifically recommend multi-process structure?

One example i found was the "make" program calling GCC to compile some source files into object files. Then piping GCC's output into another call to GCC to do the linking.

What other uses cases have any of you worked on?

Answer 1

There are three broad reasons why we'd like to start another process:

• for interacting with a different program
• as an alternative to multithreading
• as a security boundary

Programs do not exist in isolation and frequently have to interact with other programs. For example, your software could connect to some server. Or you could link that other software as a library. But most software doesn't support a server mode and doesn't provide a library that you could link. So it can often be useful to launch the other program as a child process and interact with it via some IPC mechanism. E.g. you might run a git command for version control stuff, or run a Python script.

The Unix operating system was designed around the idea of small, simple programs that can interact with each other. The shell is a program designed around launching, combining, and managing child processes. Make is a program for creating files by running shell commands in an order determined by a dependency graph.

Running multiple processes is the normal way to work on multiple tasks in parallel, at least on Unix. For example, the Apache web server can create a pool of multiple worker processes. Processes are also very cheap to spawn. Threads were added to Unix fairly late, around 1995. Whereas child processes are entirely separate and can only communicate via IPC such as pipes, sockets, or explicitly shared memory, threads share their entire memory space with other threads of the same process. Threads can therefore be more lightweight and more efficient, but using shared-everything memory correctly is much more difficult.

On Windows the situation is very different, where launching new processes is comparatively expensive and threads are the normal way to do things in parallel. This can make porting software between Unix and Windows a bit awkward.

Because child processes have their own memory space, the process boundary can be used as a security boundary. For example, the Chrome browser uses a process–per–tab architecture to isolate websites from another and from the main browser process. In addition, Linux supports various security mechanisms that can be applied on a per–process level, but not on a per–thread level. This includes things like limiting available resources via cgroups, limiting available syscalls via seccomp, or providing a separate file system via kernel namespaces. Under the most restrictive seccomp profile, a process can only terminate itself, or read and write alread-opened pipes. Such a configuration is useful for running untrusted code, e.g. a plugin. Such process-level security mechanisms also for the basis of containerization techologies such as LXC or Docker.

Answer 2

Amon's answer is spot on. To add to it and specifically answer your question about designs requiring multi-process architecture, look to MIMD (multiple instruction, multiple data) parallel processing or distributed memory multi-computers more generally. Because these systems (i.e., massively parallel processors, workstations clusters, CC-NUMA machines, etc) don't necessarily share memory, multiple processes is the standard (as opposed to multi-threaded parallel processing which is all the rage these days thanks to GPUs and multi-core processors).

Finally, note that your questions about creating child processes and communications between programs are (not quite) orthogonal. For instance, web services typically communicate with one another through various APIs but don't have a parent/child relationship.