3 ms·

Question: What happens (and should happen) if a GUI app forks? Do/should the windows get duplicated? Do/should two apps control the same windows? Is the answer

Question: What happens (and should happen) if a GUI app forks? Do/should the windows get duplicated? Do/should two apps control the same windows? Is the answer the same/should it be the same regardless of all the underlying stack (X/Wayland/Gnome/KDE/whatever)? Edit: I really care about the "should" part too, not just what currently happens. I've been trying to think of semantics for forking that could work in these situations but I haven't been able to think of great solutions.

tedunangst 7y ago
The connection to X is just a socket file descriptor. Two processes using it will most likely desync the protocol and result in wreckage.
manwe150 7y ago
Mainly only the address space is copied, other resources usually become shared, except threads (which don’t get resumed in the child).
theamk 7y ago
No, windows are not duplicated. Yes, two apps control the same windows. Yes, this answer is the same as underlying stack. That solution is very obivious once you realize it is exactly the same as what happens with the terminal and network connections. For example, after forking, both processes are still attached to the same terminal (what else can they do? It’s not like they can make new terminals - what if it was an ssh connection). They better agree who gets to read/write, or user will get confused - in shell, the parent voluntarily stops accesing terminal until the child is done.
- mehrdadn 7y ago
  It's not clear to me if you can really just solve this like you can with the terminal case. The thing with a terminal is that it's insanely easy to fork streams -- you can just interleave the streams, and even without active cooperation between the processes you still get a behavior that has some semblance of semantic sense. But with a GUI system, you're not just dealing with a pipeline; you're dealing with a state machine. Do you really take a similar approach? When a window receives a message/event, which process responds? If multiple processes respond, which message/event gets sent and which gets discarded? If only one responds, does the same process also get the reply to the reply, or might the fork get the reply instead? You could interleave events randomly here too, but it seems like far less sensible of a solution than with the terminal case.
  - chrisseaton 7y ago
    the Answer to most of your questions is that the GUI would quickly break after being forked.
the8472 7y ago
you close the file descriptors in the child process to avoid interfering with the parent, you can do this automatically on execve if they are marked with FD_CLOEXEC or you simply avoid touching them. remember that forking only creates one new thread in the child process, there won't be any code running that you don't control or that would know about those file descriptors existing.

tedunangst 7y ago

The connection to X is just a socket file descriptor. Two processes using it will most likely desync the protocol and result in wreckage.

manwe150 7y ago

Mainly only the address space is copied, other resources usually become shared, except threads (which don’t get resumed in the child).

theamk 7y ago

No, windows are not duplicated. Yes, two apps control the same windows. Yes, this answer is the same as underlying stack. That solution is very obivious once you realize it is exactly the same as what happens with the terminal and network connections. For example, after forking, both processes are still attached to the same terminal (what else can they do? It’s not like they can make new terminals - what if it was an ssh connection). They better agree who gets to read/write, or user will get confused - in shell, the parent voluntarily stops accesing terminal until the child is done.

mehrdadn 7y ago
It's not clear to me if you can really just solve this like you can with the terminal case. The thing with a terminal is that it's insanely easy to fork streams -- you can just interleave the streams, and even without active cooperation between the processes you still get a behavior that has some semblance of semantic sense. But with a GUI system, you're not just dealing with a pipeline; you're dealing with a state machine. Do you really take a similar approach? When a window receives a message/event, which process responds? If multiple processes respond, which message/event gets sent and which gets discarded? If only one responds, does the same process also get the reply to the reply, or might the fork get the reply instead? You could interleave events randomly here too, but it seems like far less sensible of a solution than with the terminal case.
- chrisseaton 7y ago
  the Answer to most of your questions is that the GUI would quickly break after being forked.

the8472 7y ago

you close the file descriptors in the child process to avoid interfering with the parent, you can do this automatically on execve if they are marked with FD_CLOEXEC or you simply avoid touching them. remember that forking only creates one new thread in the child process, there won't be any code running that you don't control or that would know about those file descriptors existing.