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?

  • It's not clear exactly what you're asking. Do you want to know if there's a good reason to use one process for each window? Or do you want to know how to do it? – Blake Nov 22 '19 at 12:40
  • How much interaction is there between the documents? Is it just copy/paste? Or can separate documents be connected together in some way? – user253751 Nov 22 '19 at 14:03
  • It's sounding like the opinion is "It's fine unless there's a specific reason for it not to be", which as far as I can tell there isn't. This is kind of what I expected but at the same time (like I said) it feels non-trivial. I wanted to make sure I wasn't setting myself up for problems down the road or committing some kind of faux pas. Admittedly, I can be over-cautious about these things as a developer. – squeevee Nov 22 '19 at 22:14

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.

|improve this answer|||||
  • I would consider Chrome in the same category as Firefox in that they are taking an extraordinary measure so that memory-intensive resources (i.e., web and JavaScript engines) do not have to be instantiated multiple times, (and probably some other performance benefits). For my own application, I don't anticipate any significant load time or memory overhead on a per-process basis. It wouldn't be so much a question of performance but state sanity and shared data. Do you perhaps have a recommendation for a tool to manage an application's processes that supports Linux and Windows? – squeevee Nov 21 '19 at 7:59
  • Will there be many users concurrently accessing said data? Will their actions change the state of said data? That being said, spawning multiple processes would not be the main issue here, rather how you serve out the most updated data. Say 1 user, multiple windows, but they all query a certain data source periodically or on request. This should be totally fine. Add 10 users, then there would be some locking issues you may want to consider. Otherwise I think you would be good to go! – ThomThio Nov 21 '19 at 8:05
  • Thanks. My application won't be dealing with multi-user concurrency, only possible concurrency within one user session, and not to such a degree as that. Just wondering if there would be complications in the process/window stuff I hadn't anticipated. – squeevee Nov 21 '19 at 8:16
  • Just saw the updated comment. To clarify, managing the processes meaning seeing the processID, application name, option to kill, pause, restart? Also seeing how each is impacting memory usage and threading? You can try SpiceWorks Network Monitor. Seemed pretty good, and is free :) – ThomThio Nov 21 '19 at 8:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.