Who deletes the Worker object moved to a QThread?
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:
Quote:
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.
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).
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.
Re: Who deletes the Worker object moved to a QThread?
I can't find anything definitive either. The best I can suggest is to put a breakpoint in the Worker Object's destructor and see if it hits, then examine the call stack to find out who is deleting it.
Quote:
I guess part of my confusion is the difference between being the owner and being the parent -- which I thought were synonymous in Qt.
Well, not exactly. Being an owner means you control the lifetime of the C++ object instances you own, so you determine when they go out of scope and get deleted. If you are owned, you may not be able to find out who your owner is. Being parented is a more formal, hierarchical arrangement, eg. in Qt you can call QObject::parent() and get a pointer to your parent QObject (who is also your owner).
An example: QTableWidgetItem instances are owned by the QTableWidget they are set on, but they are not parented by the QTableWidget. On the other hand, if you call QTableWidget::setCellWidget(), the QWidget pointer you pass in becomes both owned and parented by the QTableWidget.
