lua-users home
lua-l archive

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

>> 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.