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

Phil Thompson phil at riverbankcomputing.co.uk
Tue Aug 17 12:45:17 BST 2004


On Tuesday 17 August 2004 10:18 am, Phil Thompson wrote:
> On Tuesday 17 August 2004 10:04 am, Toby Dickenson wrote:
> > On Monday 16 August 2004 18:51, Phil Thompson wrote:
> > > On Monday 16 August 2004 5:43 pm, Toby Dickenson wrote:
> > > > On Monday 16 August 2004 17:09, Truls A. Tangstad wrote:
> > > > > It's a hard pill to swallow though, since this means our
> > > > > application will have to be infected with Qt in layers not at all
> > > > > related to GUI, just because GUI components can register callbacks
> > > > > etc. in them.
> > > >
> > > > Indeed. We have been making the same mistake, although without the
> > > > obvious ill effects of your example.
> > > >
> > > > Where does this limitation come from? The Qt threading documentation
> >
> > doesnt
> >
> > > > mention a requirement to use QThread, so I assume it comes from PyQt
> > > > somewhere.....
> > > >
> > > > Is there any other way to signal an event of any kind into Qt's event
> > > > loop from a non-QThread thread?
> > >
> > > Hmm - don't go rushing around changing code just yet. I may be able to
> > > remove the limitation for SIP v4.
> >
> > Im assuming this 'right' solution is non-trivial.....
> >
> > Is it viable to suggest an additional API in a worse-is-better style...
> > We dont really need to be able to create python QCustomEvent subclasses
> > in arbitrary threads. Thats nice, but not necessary. I guess we could get
> > by with a single static function which takes a QObject receiver and
> > integer QEvent::Type as parameters. The construction of QCustomEvent and
> > QApplication::postEvent could all happen in C++.
> >
> > I wish I knew whether that would be substantially easier than the right
> > solution, but I still havent had time to dive into sip :-(
>
> I've tracked it down to (IMHO) a bug in Python - the new thread
> infrastructure (PyGILState_Ensure()) and the thread module don't cooperate
> properly. The problem will happen with any Python extension module that
> uses
> PyGILState_Ensure() in a thread created with thread.start_new_thread().
>
> The reason why the problem occurs in PyQt v3.12 and not v3.11 is that a
> memory leak was fixed in QCustomEvent which required the GIL to be acquired
> - and that's what triggers the bug.
>
> If the bug is fixed then I think the restrictions described in the PyQt
> documentation will no longer apply (for SIP v4).

Attached is a patch against Python v2.4a2 (and it should apply cleanly to 
v2.3.x) that seems to fix the problem. I'd appreciate any feedback and I'll 
try and get the patch into Python v2.4.

Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: threadmodule.c.patch
Type: text/x-diff
Size: 725 bytes
Desc: not available
Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20040817/30ad2fc6/threadmodule.c.bin


More information about the PyQt mailing list