[PyKDE] PyQt 3.12 introduces deadlock with QCustomEvent's destructor.

[Phil Thompson]

Please read the PyQt documentation regarding using the Python thread module 
with PyQt - you aren't following the guidelines.

Attached is a version of your script which uses QThread instead and seems to 
work fine.

Phil

On Friday 06 August 2004 3:22 pm, Truls A. Tangstad wrote:
> This problem might be somewhat related to my last post "PyQt 3.12
> introduces race condition/deadlock with QApplication.postEvent." (see
> [1])
>
> It seems that the destructor of QCustomEvent causes problems/hangs
> just by creating an instance of it and then deleting it in a thread
> other than the GUI/event/main-thread. This only occurs in version 3.12
> of PyQt, and was not a problem in 3.11.
>
> The problem does not seem to occur when sending the event object to
> qt.qApp.postEvent before deleting it, even when the posting function
> should be the only one left with a reference to the object.
>
> One rarely creates a QCustomEvent without posting it, but the behavior
> is still strange.
>
> In the enclosed example two threads are started, one creates a
> QCustomEvent object, posts it, then deletes it, after waiting to make
> sure the event handler is done with it. The second thread creates a
> QCustomEvent object then deletes it, causing the application to hang
> with PyQt 3.12.
>
> I'm running on Debian Unstable using the following package versions:
> libqt3c102-mt       3.2.3-4
> python2.3-qt3       3.12-1
> python2.3-sip4-qt3  4.0-2
>
> [1] http://mats.imk.fraunhofer.de/pipermail/pykde/2004-August/008303.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thread.py
Type: application/x-python
Size: 994 bytes
Desc: not available
Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20040816/626d6b5c/thread.bin