 |
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
 Posted: Wed Feb 04, 2009 11:25 pm
Lua thread problem
|
I know that none of you guys are real Lua API experts, but I seem to have run into a real problem with Lua "threads".
According to the Lua manual:
| Quote: |
| Each thread has an independent global environment table. When you create a thread, this table is the same as that of the given state, but you can change each one independently. |
CMUD uses the Environment to store a variable that points to the current CMUD thread object associated with the Lua thread. So when CMUD creates a new thread, it does this:
| Code: |
LuaState := lua_newthread( GlobalLuaState);
lua_pushthread( LuaState);
lua_getfenv( LuaState, -1);
lua_pushlightuserdata( LuaState, CMUDThreadObject);
lua_setfield( LuaState, -2, '_CMUDThread');
lua_pop( LuaState, 2); |
OK, what this does is to create a new Lua thread, and then add a value to the Lua thread's environment table called "_CMUDThead" that points to the CMUD thread object.
However, what I have found is that this is changing the *global* Lua environment table, and not the environment table for the specific Lua thread. In other words, the environment table for the GlobalLuaState is also getting set with the _CMUDThread object.
So it doesn't look like Lua threads have their own environment tables. And I cannot find any real information on this via Google. If anyone has any clue for where I might learn more about this, let me know. But this is one of the big causes for all of the weird Lua problems in CMUD and the reason that Lua stuff seems to get corrupted. Until I can figure out how to get a thread-specific environment table, I'm not sure what else I'm going to do. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Feb 05, 2009 12:32 am
|
Hmm, the problem seems to be that while Lua *supports* separate environment tables for each thread, Lua doesn't actually *create* the separate environment table.
I found some code that creates a separate environment table correctly, and that fixed one problem. However, now I have the problem that when you create your own global Lua functions/variables, they end up in the thread-specific table and not in the main global table.
So now I need to re-think this entire procedure. Rather than using the "_CMUDThread" name for the variable, I think I'm going to need to create an entire global table where I can look-up the CMUD thread object for each Lua thread. I just need to figure out how to create a proper unique key for each Lua thread value.
I'll let you know what I learn. But this has been a lot more complicated than I expected. |
|
|
|
|
oldguy2
Wizard
Joined: 17 Jun 2006
Posts: 1201
|
Posted: Thu Feb 05, 2009 4:05 pm
|
I noticed you're looking at the old 5.0 manual.
Here is the new one.
Lua 5.1 |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Feb 05, 2009 5:55 pm
|
Yeah, but none of this is any different in 5.1. The actual hard copy of the book that I'm using is already the 5.1 version. I just gave the link to the 5.0 manual because it came up first in the Google search.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Feb 05, 2009 6:43 pm
|
Using a global "threads" table indexed by the lua thread state seems to have worked great. A lot of the weird Lua scripting bugs are fixed now in v3.04.
|
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
