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

[Toby Dickenson]

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 :-(

-- 
Toby Dickenson