Is It Possible to Offload Creation of a QAbstractItemModel Subclass Instance to a Worker Thread for Use in a QTreeView in the Main GUI Thread?

Crag_Hack

Pretty simple what I want to do (hopefully)... is it possible to offload creation of a QAbstractItemModel subclass instance and related tree structure creation to a worker thread for use in a QTreeView in the main GUI thread? Would this necessarily involve mutexes? Can it be done with signals and slots? Do you just create the model in the worker thread then pass the QAbstractItemModel subclass instance to the main GUI thread via signal/slot? Can somebody guide me along with a little code? Thanks!

Christian Ehrlicher

The only thing you can do is to completely build it in another thread and then move it to the main thread and set it in the view.

Crag_Hack

@Christian-Ehrlicher Thanks. Can you give me a couple more details?...

There is no need to use mutexes right?

All I have to do is construct the QAbstractItemModel subclass instance and it's tree and underlying tree items in the worker thread then pass the instance to the GUI thread via signal and slot right? Then set it in the view?

Done this way race conditions are not a problem right? Due to signals and slots being thread safe?

Lack of reentrancy for the QAbstractItemModel class is not a problem right?

Anything else to know?

Christian Ehrlicher

@Crag_Hack said in Is It Possible to Offload Creation of a QAbstractItemModel Subclass Instance to a Worker Thread for Use in a QTreeView in the Main GUI Thread?:

Done this way race conditions are not a problem right?

What race condition? You access your model in one thread and when you're finished there you pass it to another thread. Where should a race condition occur here?

Due to signals and slots being thread safe?

What should this mean?

Crag_Hack

@Christian-Ehrlicher said in Is It Possible to Offload Creation of a QAbstractItemModel Subclass Instance to a Worker Thread for Use in a QTreeView in the Main GUI Thread?:

Done this way race conditions are not a problem right?

What race condition? You access your model in one thread and when you're finished there you pass it to another thread. Where should a race condition occur here?

Just making sure... sounds kosher to me but race conditions are pretty scary like Freddy Krueger... :)

Due to signals and slots being thread safe?

What should this mean?

Should mean that data can be passed from thread to thread no problem as long as two threads don't modify the same copy of data.

Just want to make sure I got this right... All I have to do is construct the QAbstractItemModel subclass instance and it's tree and underlying tree items in the worker thread then pass the instance to the GUI thread via signal and slot right? Then set it in the view? Correct right?

JonB

@Crag_Hack
I don't think signals/slots, that copies data parameters. I think @Christian-Ehrlicher is suggesting moveToThread() when you are done initialising your model.

Crag_Hack

Thanks guys. Sounds pretty simple to me.

@Christian-Ehrlicher Are you referring to moveToThread() or signal/slot?

Christian Ehrlicher

@Crag_Hack To be sure you should use both - use signal/slot to pass it from the worker to the main thread and then moveToThread() to make sure the model's thread context is the main thread.

Crag_Hack

@Christian-Ehrlicher Thanks Christian. A quick followup question - does it matter which thread the moveToThread() call is placed in? I currently have the following code in the receiving slot in the main GUI thread with the given connection and am receiving this error message at runtime:

QObject::moveToThread: Current thread (0x155a2f8c260) is not the object's thread (0x155a2fe4490).
Cannot move to target thread (0x155a2f8c260)

connect(worker, &Worker::snapshotLoadSignal, this, &Replicator::loadSnapshotTree);

void Replicator::loadSnapshotTree(SnapshotTreeModel *passSnapshotTreeModel, bool cancel)
{
    snapshotTreeModel = passSnapshotTreeModel;
    snapshotTreeModel->moveToThread(QApplication::instance()->thread());
    snapshotTreeView->setModel(snapshotTreeModel);
}

Crag_Hack

Lol dude don't know why I didn't catch that error message... DUH... to move an object's thread affinity from the thread the object is located in to the new thread (the GUI thread in this case), put the moveToThread() call in the worker thread to move the QAbstractItemModel subclass instance to the main GUI thread.

Crag_Hack

Three questions to close the thread:

For the googlers out there I assume this applies to QStandardItemModel and QStandardItemModel subclasses as well right?
Does the order of the moveToThread() and signal/slot passing to main GUI thread matter? I'm guessing the moveToThread() call should come first so the main GUI thread doesn't get scheduled before the moveToThread() call and use the model before it's thread affinity changes.
Can I have your phone number @Christian-Ehrlicher in case Freddy Krueger knocks on my door? :)