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 _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt