[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua, multithreading and Qt 4.8
- From: Jerome Vuarand <jerome.vuarand@...>
- Date: Fri, 9 Mar 2012 17:38:19 +0100
2012/3/9 Michal Kottman <k0mpjut0r@gmail.com>:
> 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?
Last time I worked with Qt, you had quite precise control over how
slots are executed. Every QObject is attached to a thread, and its
slots will only be executed in that thread. A signal emitted in
another thread (by a webkit widget for example) will be queued and
processed by the QObject's own thread message pump.
Problem arise when objects move from one thread to another (with a
method pushToThread IIRC), because now some of their slots may be
called from that thread, and if the slots access your Lua interpreter,
you get concurrent access issues. But can't you simply hook yourself
somewhere to prevent your Lua-enabled QObjects from being moved to
another thread ? That shouldn't become an issue because I don't think
Qt itself pushes around objects created by the user, and that
pushToThread method is only useful when you work yourself with
QThreads.