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

[Ben Sunshine-Hill <bsunshin@...>]

What you're basically talking about is plua (see the Wiki) for Win32. It's a 
good idea, assuming full serialization like that fits your needs. Note that 
if you have any exported functions that may change their address (think DLL 
functions) those will need to be re-registered. Also, userdata won't be able 
to reliably hold references to data outside the fixed Lua arena.

Also, I'll take this opportunity to plug Pluto, a cross-platform serialization 
tool that aims to be as powerful and elegant as possible. 
http://lua-users.org/wiki/PlutoLibrary .

Ben

P.S. The next version of Pluto will hopefully be released in the next few 
days.

On Monday 21 June 2004 09:13 am, Alex Evans wrote:
> 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.