Re: Best way to save/re-load an lua state

[Andre de Leiradella <aleirade@...>]

>> This will only work if you new buffer is loaded at the same address as
>> the old one, as there'll be pointers embedded all throughout the data.
>> And if there happen to be pointers anywhere else --- such as on the
>> stack --- then you will be in for what is technically known as A World
>> Of Pain!

> A much more interesting (read: technically challenging) solution would
> be to try and use x86 segment registers to allow the buffer to be
> loaded at different addresses and have an entry in the LDT pointing at
> the base of the buffer. (I've been reading too much of Google's
> NativeClient codebase and it's usage of segments).

With lper you don't have to worry with any of this. Usually (all times 
in my tests), the OS can remap the file to the same memory address, and 
you Lua state with everything else will be in place. lper even has a 
facility to create a new state if the given file name doesn't exist, or 
to use the state in the file if it does.

What you need to worry about here though are C functions used in the Lua 
world. Your executable will probably be loaded at a different address 
every time, so pointers to C functions change at every run. There are 
some workarounds, such as making all your C functions heavy userdata 
with a __call metamethod. The metamethod would get the userdata pointer 
(that could even be an int casted to void* identifying the function) and 
lookup the function pointer in an array and then make the call.

If you pass C pointers to Lua as userdata you can also have this kind of 
problem, unless you make sure they are unserialized at the same address. 
One way to make this is to use the same allocator as lper to build 
C-side objects, but then you don't have control over this if you use 
third-party libraries. If it's the case, you could apply the same 
userdata trick described above, adding one level of indirection to all 
your C pointers when they come from Lua.

Cheers,

Andre