lua and multithreading

[Dan Marks <dmarks@...>]

Ok, now there is support in lua for multiple
contexts, and I agree at least for now for
the sake of simplicity it might be beneficial
to forego adding operating system specific code
into lua such as threading primitives because
one of lua's attractions is that it is ANSI C
code strictly.

However, as a "proof of concept" I thought the
following might be a good test.  Using a mutex
lock, have each thread lock and then assign
its own value of lua_state, run for a while,
and then inside the VM loop release the lock,
manually give up its time slice, allow another
thread to set lua_state and then grab the
lock again.  While only one lua script is running
at a time for all of the threads, it still allows
them to appear to run simultaneously, especially if
the unlock/pass/lock call can be put at a
strategic place in the VM loop to not run too
often or too seldomly.

Another idea I thought would be neat would be
to port lua to the PalmPilot.  This is not as
unreasonable as it sounds.  The executable for
i486 under Linux for lua is 59,000 bytes, which
is not too hefty for a PalmPilot app, even
including libc and possibly libm.  And if programs
are stored in lua bytecode format it may confer an
advantage too for some tasks.  The problem I see
with this is that the PalmPilot has a memory
allocation scheme that does not allow any data
to be guaranteed to remain in the same location
between program invocations.  The Pilot uses
a "database" to store persistent information,
and the operating system can sort around the
locations of the data.  If a memory allocator
was written to allocate blocks out of a database,
then a malloc()/free()/realloc() could be
created for the PalmPilot.  However, pointers
stored in the database would be invalid if the
database record was moved.  Perhaps using
the mark/sweep traversal algorithms lua uses to do 
garbage collection, we can start at the root
lua_state node and change all the pointers
that the program uses by adding/subtracting
the value between the beginning of the memory
block for new and old pointers.  This way,
lua would not have to be radically revised to
use handles to the data instead of pointers,
and the pointers could be maintained to 
point to valid data.

Does this sound like a reasonable way to
attack adapting lua to the PalmPilot, given
the type of memory management scheme I've
described?

Dan Marks
dmarks@ais.net

BTW, I apologize for the short columns but I 
am writing this on a small display.