[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua, multithreading and Qt 4.8
- From: Wolfgang Pupp <wolfgang.pupp@...>
- Date: Sun, 11 Mar 2012 21:28:34 +0100
My understanding of the problem:
Lua code creates some Qt-object.
(1) A wrapper object is created. Methods can be (re-)implemented in Lua.
(2) The wrapper object creates a helper thread (from inside Qt code).
(a) Slots in the wrapper object are connected to and triggered (via signals
from the helper thread).
(b) Methods in the wrapper object that (somehow) access Lua are directly
called from the helper thread.
(c) New wrapper objects *that access Lua* are created by the helper thread.
According to Jerome, (a) should already work by default.
(b) causes random crashes.
(c) would require newly created objects to have their own child state
(lua_newthread) and proper locking/unlocking in place (or an entirely
new Lua state)? But this case is currently not required to work anyway
(probably needed to work for creating QThreads from Lua).
A possible solution:
I imagine the main loop (QApplication.exec()) looks something like this:
while(true) do
checkAndProcessEvents();
sleep(aLittle);
end
One could unlock some global mutex while sleeping, and only allow
other threads to interfere then.
Every method possibly called by a (Qt-created) helper thread would
then need to wait on that mutex before accessing Lua...