RE: saving state

[bsunshin <bsunshin@...>]

On Tue, 29 Apr 2003, Bilyk, Alex wrote:

> I would suggest that perhaps you reevaluate what is absolutely
> necessary to save in your game as saving lua_State sounds like a
> brute-force approach. But, if you did want to save the state, I would
> simply make sure that every lua_State is in yielding and simply
> persist every data structure it owns.

But if you have an ongoing coroutine, part of its "data" is its current
line of execution. Like so:

function bakeBread()
    mixDough()
    letBreadRise()
    while(bread.volume < 2.0) do
        yield()
    end
    putBreadInOven()
    while(bread.timeInOven < 1.5) do
        yield()
    end
    takeBreadOutOfOven()
end

If we were serializing state by merely keeping track of data structures,
we'd keep track of the bread's volume, and how long it's been in the oven.
But if we serialize and then deserialize the structures like this, we have
no way of determining that the bread is currently in the oven--or even
that we've been baking at all!

A naive approach would be to have the coroutine update a "state" variable
suitable for serialization that would allow the deserializer to start up
a "completion" routine that would assume that the bread is already in the
oven, and merely wait to take it out. But for a function with n
states, that requires n-1 "helper functions" with different initial
states, all of which need to be updated if a change is made to the
original function... a logistical and organizational nightmare. And
besides, it just seems yucky.

I think a good compromise between serializing the entire state, and
pickling the structures, would be the ability to easily serialize the
callstack and local variables of a single thread. There'd be some issues
involved with resolving local references to pickled structures, of course.
Anyone with ideas?

Ben