[PyQt] Threads with PyQt. Qt's or Python's?

[Giovanni Bajo]

On mar, 2009-01-20 at 12:08 +0800, Christoph Burgmer wrote:
> Am Tuesday, 20. January 2009 schrieb Giovanni Bajo:
> 
> > On 1/19/2009 4:36 PM, Christoph Burgmer wrote:
> 
> [...]
> 
> > > I am doing a
> 
> > >
> 
> > > QCoreApplication.postEvent()
> 
> > >
> 
> > > out of "run()" from a "threading.Thread" class without any
> problems.
> 
> >
> 
> > That's only because you are lucky. It's not something that's
> officially
> 
> > supported and I have spent days debugging random crashes that turned
> out
> 
> > being Qt accesses from threads allocated by Python.
> 
> >
> 
> > I suggest you to fix your code.
> 
> We have an unlucky situation here, Qt documents neither say that
> mixing threading libraries is ok, nor does it say it could lead to
> clashes.

To be more precise, using a different underlying C-level library is not
going to fly. The question here is: assuming that Python and Qt ends up
calling the same underlying library (eg: pthread on Linux), does it work
if I create a thread from Python and then use Qt's calls?

> Now guessing won't help, but I'll do it anyway:
> 
> QCoreApplication::postEvent() is "thread-safe" and thus has the
> highest safety level one could whish for in the Qt threading system.
> It works by adding the event to the event queue and returning
> immediatelly.
> 
> It's the main event loop that then takes over.
> 
> Now from that I would assume the only clashes could occur when
> fiddeling with the event queue. Instead of assuming some magic done in
> every thread I rather believe that synchronisation is done in the
> local method, postEvent(). Now things going wrong would mean that
> synchronisation there does depend on the threads all adhering to the
> same special protocol, something that IMHO is not needed to complete
> this task.

For your reasoning to be true, QThread's constructor should be an empty
function. Instead QThread's constructor initializes a QThreadPrivate
object, whose create a QThreadData TLS object, who is in turn vital to
the working of, eg., QThread::current(), that postEvent() calls.

Moreover, it's not only postEvent() at stake here: you are probably
constructing an event object before passing it to postEvent(), so you
will have to check that everything also in there is compatible with
using a different high-level threading library (included, eg., object
construction and ownership transfer at both the sip/pyqt/qt level).
-- 
Giovanni Bajo
Develer S.r.l.
http://www.develer.com