Trey2k
commented
1 year ago The obvious downside to this is that we will already be breaking API compat. But as I stated in the recent beta1 release, it was never a guarantee. And actual changes needed to a GDScript source code baser should be minimal.
Currently we follow the Lua C api naming for coroutines, which calls them threads. This can be very confusing as within lua they are called coroutines and they do not behave at all like OS threads. Corouitnes describes their functionality much better. I propose we rename in favor of being less confusing.
Also in favor of being less confusing, instead of constructing lua coroutines separately from their parent state. To make the connection more obvious the coroutine should be made directly from its parent lua state. This will mean a new method from the LuaAPI class.
The LuaAPI class should also start keeping track of is children coroutines.
And finally, support should be added to pull a LUA_TTHREAD from the lua state. This will allow the use of the coroutine package to create new coroutines from within lua its self.