RE: lua state serialization (WAS: Lua state) :: a poll

["Alex Evans" <aevans@...>]

Hello, 
One solution to this problem which I am toying with the idea of using,
is to allocate a pool of memory for use by the entire Lua environment
(ie the LuaState and all its allocations), and point Lua's memory
allocation/freeing hooks to a custom memory allocator which only
allocates within this pool.

Then (portability-friendly people look away) make sure the pool has a
fixed physical address (see below) and just dump the whole pool to disk
as a block of ram! (fwrite...) Then you can reload and restart lua just
by freading it back at the same place in memory, no fear of needing to
do any pointer fixups. 

This has the advantage of serializing the entire lua state, all VM
instruction pointers and coroutine state etc. all in one go. Basically
what was suggested before in this thread. But there's a simple Win32
implementation (below). Of course you can use your memory allocator's
internal tables of allocation space to skip over the unused part of the
pool when writing. And you can gz/zip the useful parts as you go...

In a game environment this is not as useless a system as it sounds,
since you're often dealing with a fairly closed, non portable system (a
game...), and it's actually very handy to have a hard bound on lua's
memory usage anyway (the fixed pool size).

In win32 the implementation is trivial: make sure you link with /FIXED
(the default I believe) and then declare a big global static array as
the lua memory pool. Its address will never move between invocations of
the program....(*). The only work then is implementing your own
malloc/free for lua, best done by fiddling with something like doug
lea's malloc source to work within your pool.

I had originally intended to use VirtualAlloc to allocate the pool space
at a fixed address (say, at 0x10000000 or whatever) but I'm nervous
about trying to allocate such 'fixed' addresses. Do any win32 gurus on
this list know if that's a bad thing to try to do?

Ok that's enough platform specific horribleness for one day.
- alex


(*)... until you change something and rebuild your program. Ahem.