[PyKDE] PyQt 3.12 introduces deadlock with QCustomEvent's
destructor.
Phil Thompson
phil at riverbankcomputing.co.uk
Tue Aug 17 10:18:13 BST 2004
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).
Phil
More information about the PyQt
mailing list