Re: Sharing objects between states

[Mark Hamburg <mark@...>]

Primitive values (booleans, strings, etc) can be copied between universes but are relatively uninteresting in more general cases (or are only interesting in the context of a more general transit mechanism).

When you have native objects managed through full userdata proxies, these can be copied between universes provided you have a mechanism like reference counting to track how many references exist to these objects. Note, however, that this won't copy the contents of the environment field so you need to decide what semantics you want to associate with that. Note also that you get no threading protection when accessing these objects if that matters.

Complex Lua data (tables, functions) cannot be directly copied. There are two choices to deal with this (besides just figuring out how to not need it). One is to implement serialize/deserialize support. While one can serialize to a string, serializing to a native data structure reduces copying costs and provides a way to add references from the serialized form to native objects. So, you serialize, move the serialized form across states, and de-serialize. The other option is to skip the intermediate form and build the data structure in the target state based on walking the data structure in the source state. I don't recommend this for a couple of reasons (and I have experience because this is how Lightroom used to work). The first argument against this is that it generally involves locking down both states for longer which may not be ideal from a threading standpoint (the usual reason to want to do such copying). The second argument is that the code gets devilishly complex to reason about with respect to exceptions because you can get exceptions in both the data structure building code and the data structure iteration code.

Mark