On sexta-feira, 15 de março de 2013 00.33.23, Etienne Sandré-Chardonnal wrote: > Thanks for the answer. This leads me to two questions: > 1) It's then unsafe to destroy the QThread in a slot connected to > "finished", as it is in fact "aboutToFinish", am I right? But deleting > after terminate() signal or after return from wait() is safe.
Correct. Deleting the sender of a signal in a slot called through a DirectConnection is almost always a bad idea. You never know what it's going to do after the signal is emitted. In particular, it's a very bad idea to do this to a QThread, starting with the fact that you can't delete a QObject- derived class from any other thread than its owning thread. You can delete it in a slot called via QueuedConnection or you can queue the deletion by calling deleteLater(). > 2)One poorly documented thing about QThread, is where are supposed to be > called exit() and quit(). While exit() naming suggests that it should be > called from the thread to terminate as in posix, the slot nature of quit() > suggests it should be called from the thread where QThread lives, ie the > parent thread. But quit calls exit(0). That's confusing... Indeed. In older versions, they could only be called from the thread that QThread started, even if they were methods in a QObject. That was inconsistent. In recent versions (since 4.6 or so), you can call them from any thread. > In other words, is it safe/clean to: > - call this->thread()->quit() (quit called from the thread) > or > - call workerThread->quit() (quit called from the parent thread where > QThread lives) Yes, both are fine. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
