Multiple main windows in one process vs multiple processes

Question

I'm making a desktop application where it would be perfectly sensible for the user to have multiple instances of the main window open at the same time (i.e., with different documents open between them).

Going by the simplest approach: if I create a second window from within my application then it will live in the same process and address space as the first window. And if the operating system launches the application twice then there will be two processes running with separate address spaces and one window each.

Some applications (e.g., Firefox) are more controlling about how processes spawn, but this seems to be an extraordinary measure taken to share expensive resources. Implementing such a feature seems very complicated, and not well supported by any tools I could find, especially if the application is meant to support multiple platforms.

Spawning every main window as a new process seems excessive and weird, plus catering to a one-document-one-process paradigm would surely limit the extensibility of the project with no benefits I can think of.

Does it actually make a difference in practice? It seems like this should be non-trivial, but (from where I sit) I think I could manage any inter-process/inter-window communication using the clipboard and database locks.

EDIT: I'm not concerned about performance, only about whether there are practical complications in terms of state consistency and data access if the application might exist in multiple processes. If so, are there useful cross-platform techniques for dealing with these complications?

Answer 1

Yes, there would be a difference.

Take for example Google Chrome. Open 15 tabs on that on your favourite websites - now open Task Manager or a Resource Monitor of some kind. You should see multiple rows of Google Chrome running - they have spawned multiple processes (and threads, if above a certain memory threshold) to handle the tabs. Memory intensive, but does the dirty job well of serving greedy users like us.

IPC is going to give you a problem if the locks are not handled well, or whose process is 'locked-out' and waiting for a dozen others to complete. Example are WinForms are updating the windows in realtime, probably through an async delegate.

Additionally, task-switching can make programs slow to a crawl if they are given priority above others, and locks and waiting events happen. Combined with the above scenario, this can lead to a big performance hit.

As such, one should pay attention to async patterns and decoupling this from the Window too.

Answer 2

There's a new feature in iOS that a user can (apparently but not really) duplicate an installed application and "run" any copy or multiple copies. The effect is that one process is launched, and that one process would know that it is responsible for more than one application. The behaviour visible to the user should be as if they had launched multiple applications. As a developer, you have to distinguish between global state and local (per apparent application) state.

The developer has to do some work to make this work correctly, and then mark his application as capable to support this feature. Applications commonly had one object representing the application itself, that won't work anymore.

Answer 3

I do not think there is a single correct answer to something like this.

The critical difference in my opinion between a single and multiple processes is that some types of faults will bring down or corrupt the entire process. So using multiple processes may give you at least some protection against these errors. Ofc, these types of errors should be caught and fixed, so the main benefit should be if you are running external code where you have less control over errors.

But most other concepts, like window ownership, belong on the thread level. So it would be perfectly possible to do a single process with one UI thread per window. Synchronization and communication between processes tend to be a bit more heavy weight than between threads, but most things should be possible regardless if you are using threads or processes to divide the work.

In the end I would go for one process per window if you do not have any special reason to do something else. This should be a easy for you, any other developers, and you users to understand.