lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

What problem are you ultimately trying to solve?

Assuming that sharing objects between states is something that you need to solve, it seems like a method such as the one you describe could be made to work (notwithstanding any sharp edges that it might introduce) so long as the `fwd` objects are userdatas that could be referenced by two Lua states.  That said, I haven't though I haven't thought enough about it to say for sure.

In principle, at the very least, Lua can by made to interface to any library with a C api, including the Lua C API itself.  So you one general way to do this would just be to expose the luaL_State pointer for L1 as an opaque userdata in L2 (being careful not to let L2 have access to the actual pointer so as not to contaminate one state with the other at the C level).  Then the result might be like this (lua code running in L2):

-- Lua code running in L2.
l2_state = some_c_function_returning_L1_as_userdata()

-- my_object, from L1, is now on the stack.

In other words, you are basically using the Lua C API, via Lua, to operate on L1 using its stack as you would from C.  This is a more low-level API then you are proposing, but you could then build a pure Lua library on top of this to expose higher level features (so that you don't have to deal directly with L1's stack).  Maybe one down side of this approach is that, when calling L2 code from C/C++, you'd have to specify the relevant L1 object by name, possibly giving it a string-named location in which to find it in L1.

Not saying this approach is better than yours, but it does seem more general.  E.g. if you wanted to call L1's `rawget` on one of L1's tables, then you'd have to expose both as `fwd` objects, and those forward objects would have to know how to "unwrap" any `fwd` objects that are given as parameters to a `fwd`d function.  Whereas with the approach above, you get automatic access to everything in the L1 state without any wrapping/unwrapping and without any predetermination of what will need to be shared.


On Tue, Jun 28, 2022 at 11:15 AM Scott Morgan <> wrote:
I'm thinking about ways to share objects between states, something I've
not needed to do before, and have come up with a possible technique:

State L1 has the actual object `obj`
State L2 is given a 'forwarding' object `fwd`

A call in L2, e.g. `fwd:foo("test")`, picks up the name of the method,
and it's arguments, than passes them into L1's state, calling the method
on `obj`. Results are then returned to L2 as expected, with non-basic
Lua types being wrapped in their own forwarding objects.

You could expose plain functions this way too.

So, given that basic outline, a couple of questions:

Q1 : Has anyone ever done this? (Is there already a lib)
Q2 : Is this viable? There's obvious marshalling overhead, and limits on
passing types, but if those aren't an issue, does it seem okay? Worst
problem may be thread syncing.