[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Too many modules? (Re: safely buffering Lua data between (system) threads & lua_States?)
- From: Javier Guerra <javier@...>
- Date: Sun, 17 Sep 2006 13:56:20 -0500
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??
Description: PGP signature