lua-users home
lua-l archive

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


From: Edgar Toernig <froese@gmx.de>

Chuck Messenger wrote:
>
> struct {
>      char *name;
>      void *addr;
> } lua_extern_t;
>[...]
> The entire Lua state would be saved, including the
> lock status of objects, tag methods, etc.

And how are you going to restore the state associated
with these userdata objects?  They will normally hold
file descriptors, sockets, or any other complex data
structure?  Often state that is _impossible_ to save
and restore.

It's completely app-specific.  Yes, there will be apps
where it won't make any sense to do a save/restore.
So you won't use save/restore for these apps.

On the other hand, there will be apps where it does
make sense.  With these apps, it's up to you to
recreate your C environment on the restore end.
What the restore API would provide is a way for you
to specify what all the new C-environment-specific
values (typically memory addresses) should be.

Ideally, the API would help you plug all the holes,
to minimize the chances for a botched restore.

With my proposal, if you fail to specify a "C object"
(user object or C function) in the externs[] array,
then lua_save() will fail.  If you fail to specify
all the same C objects on the import side,
lua_restore() will fail.

A nice touch would be to have lua_save() store
a flag with each C object indicating whether that
object is equal to zero.  On the lua_restore() end,
it checks the supplied extern[].addr field -- if
it is 0, but the flag says it shouldn't be, then
lua_restore() fails (and vice versa).

So, let's picture you trying to use lua_save()/
lua_restore() with your Lua app which has an
open socket.  When to do the program logic to
reconstruct the externs[] vector for lua_restore(),
you ought to come to the realization that you
don't know how to reconstruct your socket value.
If you forget to reconstruct it (i.e. leave it
at zero), then lua_restore() will catch the
error.

At this point, you need to make an architectural
decision.  Perhaps the thing to do is to close
your open socket, and delete the corresponding
Lua user object from the Lua environment, then
do the lua_save().  Or perhaps you'll have some
way to restore the open socket on the
lua_restore() side.

  IMHO just forget about trying this kind
of snapshotting.  Saving basic Lua types (numbers,
strings, tables, eventually Lua functions) is ok.  At
the moment you try to touch C functions or userdata
objects you'll lose.

Unfortunately, this isn't possible in my situation.
My only alternative is to save all the inputs to the
Lua VM -- to recreate the VM, I start from scratch
and feed it all the inputs to date.


    - Chuck