[oolua] Re: Saving OOLua State
- From: "Liam Devine" <liamdevine@xxxxxxxxx>
- To: oolua@xxxxxxxxxxxxx
- Date: Tue, 29 Oct 2013 11:51:15 -0000
On 29/10/13 05:34, apscience wrote:
I'm afraid I haven't gotten to deep into the persistence yet. Can you
clarify what you mean by type?
My first attempt was to add a special OOLua tag which would be looked
for when OOLUA::register_class was called, this would identify that a
Proxy_class had a Lua source buffer which provided a mechanism to
recreate the instance. This buffer returned a function to do the work
and would be registered in the metatable of the Proxy_class.
The buffer called the type's constructor, however a Proxy_class
constructor is a stand alone function which is templated. So that makes
things a little harder and requires IMHO too much internal OOLua knowledge.
Ideally you wouldn't persist OOLua type's as such. (at least as I
understand them) You would just persist the objects. To load the
persisted data you would re-register the OOLua types, rebuild the C++
objects (using a different persistence/serialization mechanism) and
rebuild OOLua's index of Lua object to C++ object. The final step would
be to rebuild the Lua state. At that point execution would continue as
if nothing happened. Unfortunately the ideal scenario doesn't seem all
that doable.
I don't understand the internals of OOLua and/or Eris enough to tweak
them to my needs at this time. Hopefully in the future when I have a
little more time I'll be able to experiment with that. Currently I'm
going to implement a simple type system over OOLua and use OOLua to
export C functions. The simple type system will allow me to pass string
based ids between Lua and C++. The simple type system will provide some
degree of type safety and then I can use Eris to persist the Lua objects
easily enough.
My second attempt was to serialise the userdata and fix up the entries
in the userdata, however this lead to the following.
You mentioned you experienced the kernel panic because Eris attempted to
persist the metatable as well right? This seems to be expected behavior:
"Note that the table's or userdata's metatable will also be persisted,
if present." [1]
It was a Lua Panic for when lua_error is called in C yet it is not
protected via a lua_pcall et al. The documentation has now changed to
what you see, after I created a tracker issue for it.[1]
The third attempt was to create entries in the persistence table which
you put on the stack when calling eris_dump and eris_undump. This works
somewhat if you add an ID to classes which are to be proxied, then store
a mapping between C++ instances and Lua userdata. This ID could simply
be the pointer of the C++ class as an size_t. You could then traverse
the weak table I mentioned in the earlier message and serialise all
alive OOLua proxies. When you want to recreate the state you recreate
the proxies which were serialised, add the entries into the persistence
table using the ID as keys and the new userdata as values and call
eris_undump.
As I mentioned in the earlier message it does have some potential
pitfalls; yet if you keep them in mind then it would work I think.
[1] https://github.com/fnuecke/eris/issues/3
--
Liam
Other related posts:
