On Fri, Mar 9, 2012 at 5:28 PM, Michal Kottman
<k0mpjut0r@gmail.com> wrote:
Hello list,
I'd like to know your opinion and experience with handling
multithreading in Lua. My main question is - how to handle
multithreading that is forced onto me by the library I am binding?
The first version of my software was extensively based on multi-threading with a GIL. I changed for a coroutine based scheduler because of locking issues with... Qt.
I first tried to do some minimal locking only in entry points but this led to dead locks. I did not want to lock and unlock each time I entered or left C++ (and manage all the hassle of pushing many calls in the GUI thread with "app:postEvent") so I left this paradigm and am not turning back (this significantly reduced CPU usage and makes control flow easier).
If QtWebkit is posing problems, maybe this is a bug in Qt because it seems to me that the general design of the GUI part is to use a single thread. Can you be more precise on what calls from QtWebkit end up in the wrong thread in Lua, maybe adding something like this assert to narrow down the problem:
assert(pthread_getspecific(sLuaThreadKey) == sLuaThread);
And then it might be possible to use a (lockless) Fifo for the events and bring them back in the main thread with QSocketNotifier.
Gaspard
