lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Ok, the __index thing is really neat and works well, but I noticed one
thing: that you cannot call lua_setfenv or lua_getfenv unless you know
where the lua chunk is sitting on the state, meaning that that has to be
loaded when you mess with setting your own environment table. Is the
lifespan of these environment tables linked to the lifespan of the chunk
on the state? What if you want your new environment table to persist for
the execution of several different chunks on the same state and how can
you get to it if you don't know where the chunk is on your stack? IE you
want to get at it from inside a C function called from Lua?


-----Original Message-----
[] On Behalf Of Joel Pritchett
Sent: Wednesday, October 08, 2003 9:03 PM
To: 'Lua list'
Subject: RE: Thread woes

>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

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.


-----Original Message-----
[] 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.


-----Original Message-----
From: Joel Pritchett [] 
Sent: Wednesday, October 08, 2003 7:47 PM
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.