I need to give a little background in order to make my question understandable. I have an GUI application that uses several threads that can handle event processing. I've spent weeks looking over various articles on QT Threading and decided to use the Worker Object model presented in the official documentation (QT5.5.1 Assistant). My only code deviation is that I do not emit a finished signal from my Worker Object, so I can not create a connection to deleteLater(). Note: My Worker Object never has a finished state; the Worker Object must be viable until the application is terminated.
Upon application termination, I need to delete the Work Object -- and currently I do so in the main thread. While this seems to work, the documentation I've read states the following:
That last sentence says that after a call to moveToThread, the owner of the Worker Object is no longer the thread that created the Worker Object (obviously). However, the documentation doesn't say whether or not the thread that receives the Worker Object becomes it's parent. If it did become the parent, then I would expect it to delete the Worker Object (just like every QObject with a parent does).Calling delete on a QObject from a thread other than the one that owns the object (or accessing the object in other ways) is unsafe, unless you guarantee that the object isn't processing events at that moment. Use QObject::deleteLater() instead, and a DeferredDelete event will be posted, which the event loop of the object's thread will eventually pick up. By default, the thread that owns a QObject is the thread that creates the QObject, but not after QObject::moveToThread() has been called.
If it doesn't become the parent, then how could the Worker Object get deleted except through its pointer in the thread of origin (or deleter(), which I cant exactly use in my situation)?
I guess part of my confusion is the difference between being the owner and being the parent -- which I thought were synonymous in QT.
Bookmarks