1. It doesn't handle tables as keys. But it does assert so you at
least won't continue blindly on (though you may still not be happy
when assert terminates the program). This probably doesn't matter
for your intended use case.
2. It doesn't recognize shared tables. This probably isn't an issue
for your use case.
3. It doesn't depth check. This is only a problem if you have
cyclic data structures.
4. It has trickier error behavior than one would like because you
can get errors on either Lua state and probably at least one of
these isn't running protected at this point.
Serialization in one state and deserialization in another becomes
very tempting because it also allows one to reduce synchronization.
This is what I had done.
1. I can handle tables as keys.
2. I ignore shared tables, only the first data get copied.
3. I ignore cylic data structures, cylic data structures are not
copied.
4. serialization/deserialization solves the synchronization problem so
that both Lua states can run in protected mode.
What I cannot deal with is
1. userdata structures, I simply ignored all unrecognized data. That
is not an issue for me.
2. functions, functions can be saved in key and values, I haven't
found a decent way to copy a function from one lua-state to another
lua-state. For this reason I don't think my code are very much useful.
since lua is a function-programming language I think a decent
serialization / deserialization should deal with function.
