Skip to content
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

Open
RadiantUwU opened this issue Nov 9, 2023 · 4 comments
Open

Feature Request:Cross VM object support #185

RadiantUwU opened this issue Nov 9, 2023 · 4 comments

Comments

@RadiantUwU
Copy link
Contributor

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 and push_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.

@Trey2k
Copy link
Member

Trey2k commented Nov 9, 2023

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.

@RadiantUwU
Copy link
Contributor Author

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 lua_xmove

@lucidium4
Copy link

Here a quote regarding sharing objects in lua Source

Yes, you cannot "easily" pass objects between Lua states. You can serialize raw data, but you cannot really pass Lua index references and upvalues and so on across Lua states without doing some serious marshalling. But generally you only have one main Lua state which is shared within your program.

@Trey2k
Copy link
Member

Trey2k commented Feb 21, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants