[PyKDE] Re: Threading problem with PyQt4 and Macosx

[Matt Newell]

> >
> > It seems that I need to work out how to find the thread affinity of a
> > Python object...
>
> ...which doesn't seem possible. So I think it's a case of clarifying the
> documentation...
>
Shouldn't this be possible for python callable's that are members of a QObject 
derived python class?  

> If you connect to a SLOT() then the slot is executed in the thread as
> described in the Qt documentation.
>
> If you connect to a Python callable then the slot is executed according to
> the same rules with the additional proviso that a SLOT is created on the
> fly in the thread in which the call to connect() is made.
If the slot(python callable) is a member of a python class that is derived 
from QObject, then the PyQtProxy object created should then be moved to the 
same thread that the QObject is in, using QObject::moveToThread.  That way 
the slot is called in the same thread as the QObject, which follow the same 
behavior as qt.  The only exception will be when a python callable that is 
not a member of a QObject derived class is used, then it will be called in 
whatever thread the connect call is made.

> You can then get your sample-thread example working by either moving the
> connect() call to the __init__() method, or by making the connection a
> direct one (or an auto one). In the first case the slot will execute in the
> main thread, and in the second it will execute in the sub-thread. As the
> slot is updating the GUI then you want to do the former.
>
> Matt - does this explanation still mean that the GIL needs to be released
> in QObject ctors etc? Or have I got 2 separate issues confused?
>
They are 2 separate issues, but after reviewing the relevant qt code I'm not 
sure if it will be required to release the GIL for qobject ctors/dtors.  It 
may work to require the GIL to be *LOCKED* whenever calling qt code that can 
hold a qt lock while calling back into python code(emit calling 
qmetatype::construct is currently the only place I know of).  

I'm still not 100% sure about all this though, and I think there may be a way 
to eliminate the deadlock situation by a simple change to the qt code.  I 
need more time to think about it, it kind of makes my head hurt:)

Matt
> Phil
>
> _______________________________________________
> PyKDE mailing list    PyKDE at mats.imk.fraunhofer.de
> http://mats.imk.fraunhofer.de/mailman/listinfo/pykde