I finally have all my base tests working for my scripting environment.
The temp plug-in .dll that is loaded by Unity, dynamically loads the actual target .dll so there is no issue when rebuilding the .dll and Unity is still holding on to the file descriptors and locking it. From there it gets commands to run some Lua/Asm string or file. That creates a separate process that runs the code for you. Depending on your environment, the process can be either a 32 bit or a 64 bit process. If Unity is only a 32 bit process, the script processes can just as easily be 64 bit if the machines is also 64 bit, which most machines should be these days. The runner process creates a thread for listening in on stdin for any input and messages from the host, and forwards those inter-thread via zero-mq to the Lua/asm code if it wants to listen.
The dll then monitors the stdout, stderr from the processes created and posts those via inter-thread zero mq for you to pull when needed. It also has a threads spawned for listening for input via stdin, to send to the other processes.
So these Lua/Asm scripts reside in separate memory spaces encased in structured exception handlers that report back to the monitoring .dll when the script processes crash for some reason. The processes can also be terminated safely via a .dll injection to make sure that all libraries and buffers are exited and flushed when killed.
Took a little while to get here, but I am there now and I have an environment of scripting that should not interfere with its controlling process unless it tears the whole machine down.
I call the library “laz”, which just stands for “LuaAsmZmq”.
See, there are some cool features you can make when you know system programming and you are not just creating your own virtual machine within the game. Utilize the OS features for what they are there for and you can get a lot of cool stuff for free.
Now, for me to plug this into the game and continue with its development.
V 