LuaRef and lua threads (coroutines)

[Mellnik]

I am using LuaRef to save values from Lua that will be later restored to Lua on request. This can happen from inside a coroutine.

When calling LuaRef::push the value will always be pushed to the state on which the reference was created with. The problem is that values can be saved from the main Lua thread and later be restored from another Lua thread. In this case the push will fail.

A workaround could be to always call LuaRef::moveTo before pushing the value. But that would be totally useless because the Lua registry is global and not per thread. The function is doing nonsense by calling luaL_unref on the first thread and then calling luaL_ref again on the other thread, effectively doing nothing.

Please make LuaRef::push(lua_State* L) to actually push the values on the given state and not the saved one.

[kunitoki]

The lua state saved inside LuaRef is needed to perform several methods not requiring you to pass the state all the time, making the whole lua ref management tedious. But of course it will bite you when mixing LuaRef from different coroutines

[Mellnik]

It's fine caching the state for internal operations but this is unrelated to pushing values to another Lua thread.

[kunitoki]

Yes we can change that one

[kunitoki]

I tried allowing passing the lua_State* from outside to LuaRef::push but the whole test suite crumbles with failures, crashes and freezes, so i'm not sure what would be the best way to handle that. I would say moving the ref with moveTo before pushing might be more explicit than internally moving things across states.

[Mellnik]

To be really correct it would require to rewrite LuaRef then. Because it is 100% valid to push values from the registry to different Lua threads.

You probably know but for the tests you can save a value in the main thread to a LuaRef. And then create a coroutine in which the value is being retrieved again.

If you don't want to support it then the whole moveTo should be really fast because it would require to call that on every single push operation....

[kunitoki]

Indeed, and LuaRef should just keep the int as member but no lua_State*. This will force you to provide the state from outside for every operation.

[kunitoki]

It's not that i don't want to support it, but it's a very centric and delicate part of luabridge. If you just need to be able to push it in a different state, should i also update the locally cached state based on the last state it has been pushed to ?

[kunitoki]

@Mellnik see if this can work for you

[rpatters1]

Is there any enforcement to prevent code from attempting to push a LuaRef to an entirely different Lua state? I'm guessing this will not work, but it opens up the possibility for bugs.

In my environment a script can launch another script in a separate (clean) Lua state. The issue comes with how to push the return value of the launched script back to the calling script. Right now I am converting the return value to a string and pushing that back to the caller. But this change tempts me to try to push the value itself back to the caller. Of course I haven't done it because I don't think it will work, but the API invites it.

[kunitoki]

At the moment there's an assert checking the states are compatible (like we had before). We could also make it throw a custom exception