im using lua 5.0 with lua.net. it works as long i dont create Lua objects in two different threads. every thread has its own lua object, no object is shared between threads. is it a lua problem or an issue with lua.net?

I'm not familiar with the .NET version. Assuming there is no big difference to the c impl. you might want to take a look at the lua_lock/lua_unlock macros int lstate.h and the description of said macros in the same file.

thanks, i will have a look.
the .net version just wraps the c version so there shouldnt be a big difference.

If you check out www.lua.org on the user contributed site, you will find a project called luathread. I havent looked at it myself though...

Hah! See? I knew I wasn't the only one!

I had very similar problems with lua when I tried to make an SDL/lua game engine that utilized about twenty different threads, several of which had independent lua states. The program seemed to work until I got really far into development, and I couldn't figure out why the thing would spontatneously crash. I then realized that lua is in fact not threadsafe, though it mentions multiple threads in the manual.

I ended up re-designing the entire stupid engine to fix it...

Basically, I found out that lua cannot run safely in different threads, and a single state cannot exist in multiple threads if any data is shared between the threads. For example, global variables, whether lua or c, cannot be accesses safely from different threads without the incorperation of mutexes or "critical sections."

How I fixed it:

First, instead of using a different lua state for each thread, I made one global lua state and synchronized it between threads. I made sure that the state was initialized before any other threads began executing via windows object flags.

I then wrapped SDL's mutexes in a pair of lua functions named Arrest and Release. Whenever a lua script needed access to global variables, it would surround the code with a pair of these functions:

Arrest();  GlobalRenderState = 1;Release();

This affectively makes a "critical section" within the script. This means that once a thread starts parsing and it passes an Arrest call, it cannot pass execution to other threads until it gets to the Release call.

However, this approach isn't fool-proof, and it drastically slows down execution time, becuase it forces each thread to wait on other threads before continuing.

It seemed to suffice for me, but I wouldn't recommned trying that approach. It would be wiser to, instead of relying on the OS's threads, use lua threads to parse several scripts at once.

This ensures no thread synchronization problems, since they aren't really separate threads--just one thread parsing several scripts.

This is hard too though since it must be explicitly handled within the scripts. For example, you have to manually pass execution from thread to thread with special lua functions, which are declared in one of the libraries.

Using this approach meant that I had to redesign everything.

I ended up making a lua function "main" that was parsed entirely every frame, along with "onkeypressed" and "onmousemove" etc functions. This worked and didn't need multiple threads at all.

Sorry I couldn't help much, but hope that helps a little. I hope I have all my fact straight; I haven't touched lua in over a year, but it is funny you mention it because the only reason I'm online right now is to go and re-download the lua library for my next project...

the difference to your problem is that i dont share any data/state between threads.
i have a client and a server, each has its own lua state.
when i run both in one process things get messed up.
strange: even if i syncronize lua calls with a mutex i still have the same problem...
seams the easiest solution would be to always run client/server in seperate processes.

I have a project where I need to use lua.net, but the site seems to be down. I'm hoping this is temporary, however, does anybody know of an alternate locations I can download it, or some other way to get the dll?