Multi-process software: boon or bane?

If ever you've used Google Chrome, you'll notice that if it has multiple tabs, multiple copies of the executable (chrome.exe under Windows) will show up in the operating system's process manager (Task Manager under Windows), even though there is only one window open. How does this happen, I'll write later. For now, let's focus on its strengths and weaknesses.

Before I proceed, some terminology round-up:

• Process - a running instance of a program / executable file
• Thread - A function running as a "mini" process within a normal process
• Mutex - An object used by operating systems to ensure exclusive access to a resource, such as memory and CPU time
• Context switch - The process of telling the CPU to execute/resume execution of another function

One of the good points of the multi-process concept is that a crash in one process does not affect other processes, thereby making the system more stable and resistant to software bugs that are sufficiently fatal to bring down a computer (bluescreen in Windows, kernel panic in Linux/Unix.). This is in contrast with threaded software, where a crash in one thread will cause all other threads in a process to be killed as well without an opportunity to clean up, thereby leaving dangling objects like mutexes which can choke up other processes and cause system crashes. Also, multi-process software can be designed so that each copy of itself may run as a different user with the same, greater, or less privileges, compared to threaded software where each thread is tied to the privileges of its container.

With the good comes the bad. Processes require more resources like memory to maintain, and it is costlier to do context switches between processes than between threads, since a process context switch involves saving/restoring more data than thread context switching; that's why it is easier to run out of memory with multi-process applications. This consideration especially applies with embedded-system operating systems, such as those found in the iPhone and iPad. Another disadvantage is that, implementation-wise, a multi-process executable is harder to code.

So, is this concept good or bad? The answer is that it depends on the program's purpose. For Web browsers, this is good, because, from a security standpoint, you have no control over the code in the Web pages served to you; it may be containing malware. For games, the very nature of its coding makes it impossible to spawn (branch out) its operations across multiple copies of itself, since process switches are not deterministic.