On 2015-05-27 16:41, Thiago Macieira wrote: > On Wednesday 27 May 2015 15:02:36 Matthew Woehlke wrote: >> On 2015-05-18 03:46, Thiago Macieira wrote: >>> On Thursday 14 May 2015 18:18:52 Robert Daniels wrote: >>>> moveToThread(this); >>> >>> This is wrong. Never do "moveToThread(this)", since it's very difficult to >>> then destroy the QThread object. This is unrelated to the problem and >>> it's probably only for simplicity of your testcase. >> >> Sort of OT, but... why? If the object in question is destroyed by the >> same thread that created it, after the thread that the object >> "represents" has terminated cleanly, what is the problem? > > The problem is a QThread living inside the thread that it started. > > You can't destroy that object inside that thread because the QThread > destructor will wait() until the thread exits. And the thread can't exit > until > the destructor has returned. That's a deadlock.
Right. An example probably helps. What's wrong with this approach? class MyThread : public QThread { ... } // has moveToThread(this) int main() { auto* t = new MyThread; t.start(); // ... t.wait(); delete t; // QThread deleted from main thread, not itself } The QThread is memory-managed from a thread other than itself. It's just that the thread affinity is circular. Note that I am *NOT* trying to deleteLater the QObject! (Because, yes, that would be horrible! And for that matter, would leak, since in my usage, the thread has exited before I try to delete it.) Anyway, a more accurate depiction of my case is: class MyThread : public QObject { QThread self; MyThread() { moveToThread(self); } } ...where again, it is assumed that MyThread is deleted from a thread other than MyThread::self. Is this approach broken? (I think no? It seems similar to the alternate approach you gave.) -- Matthew _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest