Re: Too many modules? (Re: safely buffering Lua data between (system) threads & lua_States?)

[Javier Guerra <javier@...>]

On Sunday 17 September 2006 11:28 am, Asko Kauppi wrote:
> Not really. What I have in mind is similar in concept to the notion
> of processes, and an OS, but they will actually be run as threads in
> a single process. This way, they can use a C module (malloc/free) for
> data exchange.

I think there's a continuum of separations when you think of Lua multitasking.  
some easy to recognise points are:

A- several processes accessing the same SQL DB server
B- having the DB server on the same machine as several (Lua) clients
C- use a memory-backed DB server.
D- a DB-like C API to access a POSIX shared memory space, using semaphores
E- a single process creates several separate LuaStates, each on an OS thread, 
accessing a POSIX shared memory
F- keep the DB-like API to access malloc/free blocks of memory instead of 
POSIX shared memory
G- add metatables to make the DB-like API look like Lua tables
...
...
...
M- related LuaStates, running one at a time
N- implement locking to run related LuaStates on OS Threads (LuaThread)
...
Q- finer-grained locks to allow more that one state some degree of simultanous 
access to the storage 
...
Y- coroutine-based cooperative multitasking

IMO, it shouldn't be too hard to implement F,G; but a nearly ideal would be 
Q... could that be a goal for Lua6??


-- 
Javier

Attachment: pgpqSB54_61YV.pgp
Description: PGP signature