There are currently three functions for launching a script in a system thread:
gh_utils.execute_script(script_name, threaded)
gh_utils.execute_script_v2(script_name, threaded, create_worker_wind3d)
gh_utils.execute_script_v3(script_name, threaded, create_worker_wind3d, affinity_mask)
where:
- script_name : string, name of a ZOMBIE script
- threaded: 0 or 1 to start or not the script in a system thread
- create_worker_wind3d: 0 or 1 to create or not an invisible window with an OpenGL context (shared)
- affinity_mask: thread affinity mask (for windows only)
So if you want to create OpenGL textures in a threaded script:
gh_utils.execute_script_v2("resource_loading", 1, 1)
In this thread script, you can use all Lua/Python functions. All gh_renderer / ghtexture, gh_gpu_program functions will work but they will use a new renderer that has a rendering context shared with the main renderer.
Now an important thing in Lua (and maybe in Python too, I can't remenber, you have to test to be sure): each Lua script in a separate thread has its own virtual machine context and can not share variables with other scripts. In Lua there is no lock, each script can run at full speed in its thread. This is possible only because each script lives in its own world.
To share data between scripts, GeeXLab has a special API for that: gh_utils.shared_variable_xxxxx(). Thanks to this API, you can create special variables that are visible from any scripts in read/write. You can even communicate between a Lua and a Python script.
Now for the thread safety side... it's up to you to manage threading issues. If you need it I can add a function that creates a thread lock (via a mutex on Linux).
Managing threading it not easy (and GeeXLab has only a basic support of threading) so do your tests and let me know if you have weird crashes.
I will try to look at the do_screenshot() issue when the function is called from another thread.