Well I was looking how lper works. It is based on memory mapped file with fixed address. That way it doesn’t need to update the pointer and have information on the internal structure of lua states. Until now I have always used libraries that knew how to stream data or swizzle pointer (with c++ actually). I’m thus not sure how cumbersome it can be to use fix address.
Then I had to restore pointer to function or member as there is no way to control where the code is reloaded, especially regarding the shared libraries (kind of plugins). All libraries in Lua are using callbacks as pointers to function so I wonder if there is no limitation with persistent states, eventually when using dynamically linked libraries. I’m not sure if function pointers are copied by value in lua stack.
Behalf Of Asko Kauppi
A mechanism like this (but in C) is used in the Maemo / N770-800 software, and most likely many embedded devices with low memory. When switching away from applications, they might either remain on memory, or be killed away with their state stored on disk.
With this in mind, I created a "resurrection" mechanism to Lua Lanes. It essentially does the same, but automatically. Whatever you have in the 'state' global table will be returned to the main thread if yours gets cancelled.
The Maemo / Nxxx way relies on the process to detect that it was killed last time, and to restore its state immediately at next launch, as if it was there in memory all along. With Lanes, resurrected threads would get the same 'state' as they were left off, but need to draw GUI things etc. to according state themselves. My experience is, this is a sound model to work with, and even self-documenting in that if you place something in 'state', you mean it to be persistent.
The goal I have with this, is being able to --eventually-- toss running Lua processes not only in time, but from machine to machine, without losing their "current" state. Similar to net desktops.
Grellier, Thierry kirjoitti 3.8.2007 kello 11:24:
Some libraries exist that rely upon memory mapped file to dump the heap and restore it with the needed pointer swizzling. I wonder if there is some interest in using this kind of techniques for a lua state, so that long run could have regular snapshots that would allow restarting runs from the last snapshot, in case of crash, or any other reason. Another possibility is to serialize the state but if the code is self generating, it may be boring and well no generic serialization is provided by a standard library or the language.
So I wonder,
1/ is someone interested in a persistent framework for states?
2/ if yes, would you like it as a core extension, or would you prefer external generic/specific serialization?
3/ how complex would it be to restore hashed structures pointer that lua interpreter does maintain with a virtual memory scheme?