RE: Thread woes

["Joel Pritchett" <jpritchett@...>]

>You could also use setfenv() to set explicitly the execution
environment of >each co-routine.

When you call 'lua_newthread' the object given back to you automatically
has the same global environment table as did the state it was created
from. So right now if I get the environment table through 'getfenv' I
get the global table that the master state currently has. This is more
or less what I want here, one large global table that has all my
libraries loaded into and is seen by every thread. You can change this
table, and if I set a new table for a thread through 'setfenv' the
thread can no longer see all of the library functions I loaded into the
states global table unless I load them into the new environment table as
well. But If I am going to do that I might as well go back to giving
everything its own state which was too heavy to begin with (memory
wise). 

Basically I'm trying to figure out a way to have both thread memory and
shared memory when using Lua threads. Or coroutines. Whatever.

I'm not running them as coroutines as described in section 2.10 of the
docs where it is all done in Lua. The way we're doing it is more like
where it talks about them in section 3.20. Each of our guys has his own
thread state and when the engine updates each guy he in turn calls
lua_resume() on his state.

Joel 

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Nick Trout
Sent: Wednesday, October 08, 2003 8:01 PM
To: Lua list
Subject: RE: Thread woes



When you say thread, do you mean OS thread or Lua co-routines (which are
type "thread")? If you mean co-routine, a Lua function is used to
establish the co-routine in which you can place any variables you like
and since Lua supports nested functions and lexical scoping any
declaration of "this" in the co-routine creation will be inherited by
the nested functions. You could also use setfenv() to set explicitly the
execution environment of each co-routine. You can basically customise
the scoping here using metamethods or by creating an environment table,
into which you place everything you want the co-routine to see.

Nick


-----Original Message-----
From: Joel Pritchett [mailto:jpritchett@sammystudios.com] 
Sent: Wednesday, October 08, 2003 7:47 PM
To: lua@bazar2.conectiva.com.br
Subject: Thread woes

I'm using lua in a game where we have a considerable amount (30+) of lua
controlled objects running around. In order to free up memory I'm trying
to get each object running off of a thread that was spawned off of a
master state. This allows me to load all of the standard libs and a fair
amount of my own into the state so that I can have a lot of objects
running around using the global copy of the libraries and not have to
load their own.

Now my problem is this: Since there is only one global table, how can I
add a unique 'this' pointer ( as well as some other game object specific
data ) to each thread as I was able to do when they each had their own
state so I can then pass this data to our functions? Is there anyway to
add them to the execution state so they look like any other variable
declared during normal execution? Ideally I'd like to be able to use
this data as if it were in the global table or had been declared in
script, but cannot find a way to do this. 

There are a lot of less than nice solutions to this problem that I'd
like to avoid.

Thanks!
Joel