I'm working with in LUA's thread and I'm using lua_newthread for this in my code must perform the same function n times.
To work with the competition's thread instantiate some threads in C + + and for each thread assigns a lua_state this lua_state = lua_newthread.
This thread's are destroyed only at the end of the application, so I'm always reuse the attribute lua_state these thread's. My question is this,
after some run time, a crash happens in the application, this can be caused by the garbage collector?
In my last application I used the command lua_gc (thread, LUA_GCSTOP, 0), and yet the error persisted.
Another strategy I tried was the end of each run of lua_resume, I added the command lua_settop (thread, 0), so that the battery was drained and
did not consume any memory space.
Please help me, what can happen?
Lua threads are not like CPU-threads. Lua is not thread-safe; you cannot execute Lua code in parallel across actual threads. Lua allows for cooperative multitasking, but not real CPU-threads.
You can call into different actual lua_State objects from different CPU-threads, but only if they are truly separate. If you created a Lua thread from a root lua_State, then you cannot call Lua code on that Lua thread while also calling Lua code on the root lua_State. If two Lua threads share the same parent lua_State, you cannot be executing Lua code on both of these Lua threads at the same time.
So you need to restructure what you're doing. Instead of using a thread, use lua_newstate to create one Lua state for each CPU thread. Each lua_State will be completely independent of the rest.
Related
I'm pulling my hairs out (that I don't have) on a big problem, but probably simple one.
I'm developing a Server application in QT.
This server will accept TCP connections and dialog with specific and proprietary Ethernet products.
Each time a product is called on this server, a new thread is created with this new TCP connection and a dialog begins with some "common" requests.
At a certain step of this dialog, the thread needs to run a Lua script to continue the process: not with a common procedure - but a specific one for each product.
This is my problem:
When I run the Lua script, I need to use methods of the Thread class (the current thread). Due to the Extern "C" declaration of C fonctions that can be used in Lua scripts I can't call the methods of my current thread, because I don't see how to program (or the principle behind) the structure of this exchange:
- the thread have N methods to send data on IP depending of the protocol (we will call this methods mythread::CClass_fn_X())
- the registered function C for Lua will be call LUA_FN_X(). This is just a gateway to call CClass_fn_X() with computed parameters from Lua)
if in LUA_FN_X() I want to do a "this->CClass_fn_X()", I can't because C LUA function have no reference to "this" of the thread.
I've tried various things the past few days and I can't find a good solution (or simply any solution) for my problem.
Please help me, I'm not requiring code, but just the principle to do that.
Also, is the Lua interpreter thread safe? Can I run separately Lua scripts in different threads?
To answer your last question, Lua is not OS-thread safe if you use the same Lua state in different OS threads, but you can safely run different Lua states in different OS threads.
Do not confuse OS threads with Lua threads, which are coroutines and run in the same state.
There are several ways to do this. If you only have one non-main thread that can call your Lua script, then your script just needs to know the thread object it belongs to and provide that as parameter when it calls into the C++. There are many strategies that can work there, but one is that you create a global variable that is a light userdata for your thread (basically a pointer or handle that is sufficient to identify thread). Then when you call your script, the script calls your C function with that light userdata: your C function must assume the userdata received is actually the pointer or handle or integer (whatever your strategy) for thread so then it can find the right Thread instance and call the appropriate method. For example, the C++ side:
// tell Lua which thread:
lua_pushlightuserdata(L, threadHandle); // threadHandle uniquely identifies thread
lua_setglobal(L, "scriptThread");
// call script:
// assumes you loaded script before and saved the compiled chunk
// as global variable "script" (other SO question shows how to do it)
lua_getglobal(L, "script");
lua_pcall(L, 0, 0, 0);
and the Lua script:
-- call C++ func:
LUA_FN_X(scriptThread);
and the C/C++ wrapper function that you registered in Lua state as LUA_FN_X:
void cwrapper(lua_State* L)
{
Thread* thread = (Thread*)lua_touserdata(L, -1);
thread->CClass_fn_X();
}
The Lua can't do much with a light userdata except pass it back to C++. If you want to query various thread methods, and there you have several thread instances that can call the Lua script, it might be worthwhile using a full userdata.
I have a program that performs very fast-paced calls to a Lua script using lua_pcall. It seems if the program calls the lua script too fast, things will foul up and cause access violations in the most random of places.
I've tried mutexes and even enabled SEH exceptions with try/catch to no avail. Error functions are in place and I'm checking all of the approprate return codes; the problem is an actual access violation deep within the pcall, not a safely handled Lua error.
A lot of the time the break occurs in luaV_execute, but sometimes it's in other random places. I've checked to make sure all parameters pushed to the stack are valid.
Is there a way to force Lua to complete a call before returning, or some way to ensure the call stack doesn't get corrupted?
Although the Lua system as a whole is fully re-entrant, individual lua_State instances are not in themselves thread safe.
If you're accessing a lua_State from multiple threads, you should use a mutex or other locking mechanism to ensure that only one thread at a time can manipulate that state. Simultaneous accesses could easily result in the sort of corruption you're seeing.
If you're working with multiple lua_State instances, each state can have its own access lock; you don't need a single global lock for the whole Lua runtime.
Is there a way to know which thread (coroutine) executing a Lua script is at the origin of a lua_pushcclosure call?
In order to manage some stuff relative to lua threads (delayed pause/resume, or private thread variables) I need to identify the thread involved in the callback. I know I can get the thread index when creating it by using lua_gettop, but I can't find a way to use it so it helps identifying the thread when a lua_pushcclosure call is issued from a Lua script.
My current system permits nested script calls, so a script can execute other scripts (each nested script call create a new thread with the same lua_state. Thus the lua_state used to get multiple thread entries in the stack.)
I'm using Lua 5.2
If you're in a C function that has been called from Lua, and you want to know what thread you're in... just call lua_pushthread(L).
How do I use a boost::thread to execute a function with each thread executing in its own memory space. So that when I allocate a new variable with in the function it only lives as an instance in the executing thread.
Just to clarify I want to spawn threads that execute the same method using boost::thread but I do not want to use locks or semaphores I just want it to execute in a separate space.
Anything you allocate inside the thread function is already local to that function, as long as they're not declared as static. Just write your code as normal (avoiding static local variables) and you'll be fine.
If you need to create a thread that is running completely within its own address space, then what you are looking to do is to create a process, not a thread. Threads by definition are points of execution running within the same address space of the parent process.
If you really need to create threads (i.e. there's still memory and other resources shared between threads), but you also need to have a portion of memory dedicated to a specific thread, then you have few options:
1) as ildjarn suggested, have thread procedure allocate local (or dynamic memory) and write your code so that each thread uses this memory that it allocates for itself
2) Take a look at TLS (Thread Local Storage). It is an API that allows you to create "global" variables which are dedicated to a specific thread. Also some variations of C++ have built-in keywords for declaring variables which use TLS under the hood.
Note that in above options you will not get automatic isolation where a thread would not be able to corrupt another threads memory. The only way to get this isolation is to spawn multiple processes (or switch to one of .NET languages and instantiate multiple AppDomains running within the same process).
I have the following code which initiate the thread.
int iNMHandleThread = 1;
HANDLE hNMHandle = 0;
hNMHandle = CreateThread( NULL, 0, NMHandle, &iNMHandleThread, 0, NULL);
if ( hNMHandle == NULL)
ExitProcess(iNMHandleThread);
My question is
What will happened if I run this code while the thread already in the running state.
I want to initiate the multiple independent threads of NMHandle kindly give me some hints to solve this problem.
Each time you call CreateThread, a new thread is started that is independent of any other currently-running threads. Whether your "NMHandle" function is capable of running on more than one thread at a time is up to you: for example, does it rely on any global state?
What will happened if I run this code while the thread already in the running state.
Another thread will start with the function NMHandle, independent of the other one.
I want to initiate the multiple independent threads of NMHandle kindly give me some hints to solve this problem.
This code actually creates an independent thread. Create a loop if you want to create multiple threads executing the function NMHandle. If you need the thread handles later (e.g. waiting for a thread to end), you have to store them somewhere.
Make sure that NMHandle is thread-safe. If you don't know what that means, you shouldn't start multithreaded programming yet!
And another hint: You're passing a pointer to the local stack variable iNMHandleThread to the thread. As soon as the function returns, the variable content might not have its expected value anymore - you should rather pass the number by value (CreateThread( NULL, 0, NMHandle, (void*)iNMHandleThread, 0, NULL);).
CreateThread creates a new thread. The new thread obviously can't be in the running state before - it doesn't have a state before it's created. Compare the simple statement int i = 42; - There's no prior value of i before 42, because the object doesn't exist yet. Obviously the old thread that calls CreateThread() must be running - otherwise it couldn't have run to the line that calls CreateThread() !
Every time you call CreateThread, you will get a new thread. You will also get a new thread handle and ID for every call. So you can't store them all in int iNMHandleThread or HANDLE hNMHandle. Consider a std::list<int> NmThreadIDs and std::list<HANDLE> NmThreadHandles;.
Furthermore, all new threads will start by calling NMHandle(). Is that function thread-safe? That is to say, will that function work properly when executed by two threads at the same time, or interleaved, or in any other random order? Mechanisms like mutexes and critical sections can be used to exclude some unsafe orders of execution.