What does it mean by "thread owns a QObject"?

haccks

What does it mean by "thread owns a QObject"? I found this in the doc

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 [...]
By default, the thread that owns a QObject is the thread that creates the QObject, but not after QObject::moveToThread() has been called.

SGaist

Hi and welcome to devnet,

Exactly what it said in the documentation you quoted: the thread in which you create the object owns it. You have always at least one thread in your application. You can create more if needed and thus you have to take good care on where and when the objects are created to ensure they are owned by the expected thread or are moved to it.

haccks

@SGaist Is it related to thread affinity? These two together confuses me. QObject::moveToThread() changes thread affinity and also the ownership of the object. Are they same?

Pl45m4

@haccks said in What does it mean by "thread owns a QObject"?:

QObject::moveToThread() changes thread affinity and also the ownership of the object. Are they same?

In this case, yes. As @SGaist said above, the thread where the QObject was created in, owns this object. If you move it to thread X, the ownership is also moved. The moved QObject "lives" in thread X now.

You can check the affinity of every QObject by calling

https://doc.qt.io/qt-6/qobject.html#thread

Like

QThread* myThread = new QThread();

QObject* obj = new QObject();

// obj in main thread where it was created
if(obj->thread() == this->thread())
      qDebug() << "Obj in Main thread";


obj->moveToThread(myThread);

// after moving, ownership went to "myThread"
if(obj->thread() == myThread())
      qDebug() << "Obj in myThread";

// ...
// "Worker" approach:
// connect signals for thread control
// and start myThread afterwards

haccks

@Pl45m4 AFAIU, a QObject living in thread means this thread will handle its queued signals/events provided the thread has it's own event loop. This is what it meant by "a thread owns a QObject?

Pl45m4

@haccks said in What does it mean by "thread owns a QObject"?:

a QObject living in thread means this thread will handle its queued signals/events

Yes, or in other words, the slot/function will run in the thread where the receiver QObject lives in.
Therefore you should also always use Qt::QueuedConnection in a connect statement, when dealing with more than one thread (or let Qt decide, which works best in most cases). If you force a Qt::DirectConnection across threads, the function will run in the calling thread and cause unwanted behavior or nothing happens at all.

haccks

@Pl45m4 Thank you! One last thing, when a QObject is moved to another thread then it can still be used/accessed in the thread where it is declared?

Pl45m4

@haccks said in What does it mean by "thread owns a QObject"?:

it can still be used/accessed in the thread where it is declared?

Define "used"...
In general, as long as the pointer is valid, it works but you should not call functions directly. Use signals to communicate instead.

https://doc.qt.io/qt-6/qthread.html#details

haccks

@Pl45m4 Calling slots as a normal function directly from main thread, reading/writing from/to a variable of QObject (using mutex of course).