Supplement the latest test results. Using Unity version 2021.3 and Netcode 1.6, it can run normally. Currently, there seems to be a problem with Unity version 2022.3.
I’m surprised this even worked in 2021.3. Unity in general has many threads performing different tasks, and forking a process does not carry all the threads to the child. So in your scenario all these threads will only remain with the parent and could prevent the child from working correctly.
What is your use case here? Why are you trying to fork Unity’s process?
The build’s DS server is used as a game server, and the fork is used to save memory and share memory for scenarios, data, and so on. My current testing project is very simple, just the most basic netcode connection. The fork method is also a reference to the solution of Unreal Engine in similar application scenarios.
So it is not recommended to use fork Unity process officially? Or do you have any other suggestions for me?
I would not recommend forking the Unity process, if only because we do not test for this scenario.
Regarding sharing data between different instances, unfortunately I don’t think I have any solid recommendations for you. We had investigated different ways of achieving this, but encountered complexities because it would have required knowing if assets are read-only or modifiable. If your data are not Unity assets, you could use something like a memory-mapped file to share data between instances.
Thank you very much for your reply. In subsequent tests, I used the waitpid method to manage the recycling of child processes. Although the child process called application.quit, it still could not be terminated. When I pressed Ctrl+C to terminate the process, the “execute unity sign” command was called twice. I suspect that there is some special management of process signals in Unity. It seems that there are indeed hidden dangers in forking the Unity process.
