 |
lua-l archive |
|
|
||
|
|
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. From:
lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On
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. -asko Grellier, Thierry kirjoitti 3.8.2007 kello 11:24:
Hello, 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?
|