I re-jimmied my wrapper .dll so that it accommodates the new library and programming set up. I found a couple of bugs with the remote thread creation for killing the remote process when running under debug. Need to set up more unit tests for some other permutations of configurations and possibilities where things could break and fix all those little bugs.
Other than that, this OS sympathetic architecture is a lot cooler when I actually see it running.
It has been 10 days since I actually started up Unity, and I fixed up those scripts that interfaced with my previous library set up to use the new improved reflection.
The other big strength of utilizing stdio and pipes between the processes instead of zmq and tcp, is that the IO buffer is only 1 page in size. On Windows, that would mean 4k. And as soon as the processes use up that resource, the basic IO operations become blocking and the process will stall until the parent .dll reads from the buffer and releases that resource. So, rouge processes will have a seriously hard time trying to interfere with the actual performance of the game.
The big difference of application creation on windows and linux, is that the Posix systems supply you with a lot better tools for utilising the OS for application creation. Utilising processes, pipes and these processing boundaries, gives you a lot more stable environment where the applications are not eating up all the memory because all their small jobs are released as soon as the processes die. But on Windows, the practice has been to create a sole application with everything in libraries and threads where you have to create massive scaffoldings to support the immensely complicated application, instead of relying on the built in features of the operating system.
So, if steam does well with its new SteamOS and more people start utilizing the Linux end for creating games, then I hope it will result in better use of the OS instead of just moving your bad practices along with you.
V 