-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request:Cross VM object support #185
Comments
For the case of threads, we can use a method similar to what ive done for callables and check if the state is different. If it is use lua_xmove. Besides threads, functions will be fixed in #155 as mentioned and any other value being moved by copy is probably expected and valid. |
This is a way different case, something that i tackled before, in this scenario, it has a different main thread, meaning different top-level state, meaning they also have different GCs and will not work with |
Here a quote regarding sharing objects in lua Source
|
Yeah, I don't think there is any way for this to be implemented. Originally I had misunderstood the xmove method. For the case of godot objects they are passed to lua via reference anyways. I have plans to also allow passing godot container types to lua by reference to avoid copying large data sets which I think will mitigate this issue a ton anyways. I think it is valid to have each mod have a unique state. The drawbacks will just need to be considered. |
The problem is having multiple VMs for mods that load and then be able to completely pass around objects between states, for example threads or functions.
Describe the solution you'd like
The solution would be simply making it work between
pull_variant
andpush_variant
.Currently the only issue is LuaCoroutine not working as expected. Other than that, callables/functions will be automatically fixed as expected after the pull request to solve the memory leak #155
Describe alternatives you've considered
Creating custom proxy objects to allow this, but it still does not solve the issue #155 with callables.
Additional context
This will be used between cross-mod communication, for example between core mod and the other loaded mods, or between a mod and another loaded mod.
The text was updated successfully, but these errors were encountered: