for some reason, the string which contains the data to pass to the thread is corrupted sometime after the thread is created, and it is being executed.
any leads?
it strikes me as odd since the function (which is stored in the same format) seems to be passed perfectly fine.
I experienced this, the string you get via luaL_checkstring is not safe, you better copy it using function such as strncpy
i don’t know if that’s exactly the case here, because that happens when i take numbers, too.
and the function that converts the top-stack element to the data which is sent to a thread returns a std::vector<char>, which is then converted to char* param and int paramlen, stored in the struct which houses the other data for the thread. these varibles are correct until the thread is ran.
Yes, when the thread ran, the value passed to it via lua state will be unsafe to take after a while, esspecially char*. It seems the buffer for it will be released and used for others
i’m afraid i don’t understand.
i was under the impression that pushing variables to Lua from C didn’t change them in any way
is this not true?
What he means is that you mustn’t mix the scopes of the Lua contexts.
E.g. you mustn’t use something from a Lua context on the main thread, in another thread.
For instance, if you get a const char* from Lua on the main thread, then that pointer is not valid on another thread. Even if you don’t crash, it’s just luck.
So, that’s why we’re talking about “serializing” data or “copying” the data in a thread safe manner, so that the threads can communicate.
seems i’ve hit a dead end, then - i don’t know much about pointers or how memory works to make it functional.
anyways here’s what code i had in case anyone else wants to look at it and/or try to do it (no, my code isn’t that good.).
multitedding.cpp (8.6 KB)