Thanks for the report! However, this is a duplicate of bug 504.

*** This bug has been marked as a duplicate of bug 504 ***

Closign bugs after release of 1.0.0 beta2.

(commenting to a comment on bug 504)

Indeed, this is not a duplicate. Marking it such was an oversight on my part --
sorry for the confusion.

Since this bug isn't properly resolved after all, I'm reopening it. However, if
the behaviour is identical in the C++ example, it's really an upstream issue
and there's not much we could/should do about it.

The bug in the example code, not in the bindings and it's not really a bug it's
just a unellegant exit :-)

Hugo, what about the issue of reopening windows? That at least makes the exit
mighty inelegant. :-)

I'd say we could still fix the example: they should be of a good quality, in
any case. I'm prioritizing this P4, though, as not to block more urgent things.

As I said in bug 504:

On my system I don't have any QThread problem with the C++ version, with MinGW
and Visual Studio (I didn't recompile the VS example with the 'console' flag: I
used the precompiled binary and set QT_FATAL_WARNINGS, but it exited with no
error).


The destructor ends with a QThread::wait() call, so the worst thing that should
happen is that the program could lock up, but the QThread can never be
destroyed until it has stopped running:

RenderThread::~RenderThread()
{
    mutex.lock();
    abort = true;
    condition.wakeOne();
    mutex.unlock();

    wait();
}


Matti also has a good point: it's not the first time that I get that reopening
window behavior on bugs instead of a clean crash like C++, so it might be worth
investigating.

QThread.__del__ simply doesn't get called, in fact:

from PySide.QtCore import *
from PySide.QtGui import *

class Thread(QThread):
    def __del__(self):
        print "deleting..."
        while True:
            pass
    def run(self):
        print "running..."
        while True:
            pass
        print "should not happen"

app = QApplication([])
w = QLabel("hello")
w.show()
t = Thread()
t.start()
app.exec_()


I'm really curious how you could have encountered a similar bug with the C++
version, Hugo?

I fixed the example on my machine, but I can't push it to gitorious.. why?
simple, gitorious is a crap and doesn't work.

So when (if) gitorious back to normal I'll do the merge request to make this
warning disapear.

(In reply to comment #7)
> QThread.__del__ simply doesn't get called, in fact:

It gets called, but after the sys.exit call because the window have a ref to
the self.thread object, this is why the thread don't die.

the fix is on:

http://qt.gitorious.org/pyside/pyside-examples/merge_requests/25

> from PySide.QtCore import *
> from PySide.QtGui import *
> 
> class Thread(QThread):
>     def __del__(self):
>         print "deleting..."
>         while True:
>             pass
>     def run(self):
>         print "running..."
>         while True:
>             pass
>         print "should not happen"
> 
> app = QApplication([])
> w = QLabel("hello")
> w.show()
> t = Thread()
> t.start()
> app.exec_()
> 
> 
> I'm really curious how you could have encountered a similar bug with the C++
> version, Hugo?

I just checked this... I just don't know why PyQt doesn't show the warning,
because the run method never returns and the __del__ method is never called.
Probably the thread object is never destroyed.

The problem with the Python code is that it rely on the object destruction
order, but Python don't have a deterministic one as C++ have, this is why the
C++ code works without warning and the Python one not.

I pushed the fix to the example on commit:

pyside-examples/777286a47cbee3439e439bb2cfa26bd5262c519c

Plz, check it.

I'll mark the bug as fixed as this remaining problem was not related to the bug
itself and was fixed anyway.

Ah, btw my mistake, the example works fine on C++, sorry, I got confused.

(In reply to comment #11)
> I pushed the fix to the example on commit:
> 
> pyside-examples/777286a47cbee3439e439bb2cfa26bd5262c519c
> 
> Plz, check it.

Yes it works fine.

I don't really like removing the mutex as it relies on the existence of a GIL
(CPython itself hopes to remove it at some point). A simple renaming of __del__
could do the job just as well:

--- a/mandelbrot.py
+++ b/mandelbrot.py
@@ -56,7 +56,7 @@
         for i in range(RenderThread.ColormapSize):
             self.colormap.append(self.rgbFromWaveLength(380.0 + (i * 400.0 /
RenderThread.ColormapSize)))

-    def __del__(self):
+    def stop(self):
         self.mutex.lock()
         self.abort = True
         self.condition.wakeOne()
@@ -315,4 +315,6 @@
     app = QtGui.QApplication(sys.argv)
     widget = MandelbrotWidget()
     widget.show()
-    sys.exit(app.exec_())
+    res = app.exec_()
+    widget.thread.stop()
+    sys.exit(res)


(In reply to comment #10)
> The problem with the Python code is that it rely on the object destruction
> order, but Python don't have a deterministic one as C++ have, this is why the
> C++ code works without warning and the Python one not.

Not really: I don't think Python would delete a base class instance before it
deletes the derived class instance. So it should be possible for __del__ to be
called with the guarantee that the QThread hasn't been destroyed.

Actually I lied: I didn't test your actual commit, only my patch. I assume your
commit would fail when the thread is done computing because you don't do
self.condition.wakeOne().

see reply on bug 505

release beta4