Skip to main content
Tweeted twitter.com/StackSoftEng/status/1608160872727207937
Bumped by Community user
Bumped by Community user
Bumped by Community user
Bumped by Community user
added 287 characters in body
Source Link

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?

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.

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?

Source Link

Multiple main windows in one process vs multiple processes

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.