Re: once again, cooperative multitasking?

[Mark Hamburg <mhamburg@...>]

For preemptive C threads, what I'm currently doing is generating a lua_State
per C thread and using a single mutex managed by lua_lock and lua_unlock to
coordinate amongst them. This means that at most one thread can be actually
executing within the Lua universe at once.

Now, if you had multiple universes each with multiple states and pre-emptive
threads, you could have multiple locks, but that gets really complicated to
follow.

For cooperative C threads, the existing Lua implementation should be just
fine. Just spawn multiple lua_States from a root state.

Mark

P.S. In my experience, the mutex lock and unlock calls start to become
moderately significant in profiling code when running Lua with support for
preemption even when there is no actual contention. This could probably be a
bit better if more of the stack operations could avoid locking the mutex.
They have to lock it right now to in case the GC is looking at the stack.

on 4/13/04 10:06 PM, Taj Khattra at taj.khattra@pobox.com wrote:

> On Tue, Apr 13, 2004 at 12:32:41AM -0700, Mark D. Anderson wrote:
>> I'm wondering what the possibilities are for integrating lua with
>> a C program that uses a user threading library (non preemptive)
>> such as Pth or coro, based on setjmp/longjmp.
> 
> with non-preemptive threads, i believe it should "just work" ?
> i.e. you don't need to do anything extra to make it work.
> 
> for preemptive threads or multiple procs sharing a lua_State,
> you'd need to define or more of:
> 
> LUA_USER_H
> include file included by lua.h
> LUA_USERSTATE
> additional user state (e.g. space for lock)
> space is reserved just before lua_State (see lstate.c)
> lua_userstateopen(L)
> init LUA_USERSTATE, if required (e.g. initialise lock)
> called by lua_open() (see lstate.c)
> lua_lock(L)
> lua_unlock(L)
> lock/unlock routines
> 
> i don't think this stuff is documented anywhere.  you can take
> a look at etc/luser_tests.h for an example.  since it's just
> testing the api, it declares a global lock - in real life, you'd
> probably allocate a lock per lua_State.
> 
>> Also, I presume that Lua is fine with having distinct threads
>> on the C side use distinct Lua environments, even
>> without lua_lock?
> 
> yes, each lua_State is completely independent.
> 
>> lua_lock is just if you want multiple C threads playing in the
>> same Lua environment?
> 
> yes, but like i mentioned above, if they are non-preemptive then
> i don't think you need lua_lock.