Moving QAbstractItemModel Subclass Instance from Main GUI Thread to Worker Thread When Used in a QTreeView

Crag_Hack

Hi I have a quick question - for my program I create a QAbstractItemModel subclass instance in my worker thread, then move it to the main GUI thread (using moveToThread()) to be used in a QTreeView, then I want to move it back to the worker thread to process it after the user interacts with it in the QTreeView.

I couldn't find a way to unset the model in the QTreeView. Isn't it true that if I delete the QTreeView it will delete the model as well? How do I safely move the model back to the worker thread for processing? My main concern is the QTreeView using the QAbstractItemModel subclass instance and thereby preventing a simple migration from one thread to another.

Thanks!

JonB

@Crag_Hack said in Moving QAbstractItemModel Subclass Instance from Main GUI Thread to Worker Thread When Used in a QTreeView:

I couldn't find a way to unset the model in the QTreeView.

Can't you setModel(nullptr)? Whether this whole approach is advisable is a different matter.

Isn't it true that if I delete the QTreeView it will delete the model as well?

No. The model is independent of the view.

Crag_Hack

@JonB Thanks. Should I then just delete the treeviews, movetothread() the models to the worker thread, then use signals/slots to move the model pointers to the worker thread?

SGaist

Hi,

Why do you need to move your model between threads ?

If you follow the way QFileSystemModel is implemented, the heavy lifting is done in a different thread but it's an implementation detail.

Crag_Hack

@SGaist I am using a QAbstractItemModel subclass tree as my model. Creating it can take a while as can traversing through the tree after it's been created.

SGaist

That's why that part should be handled asynchronously / using a thread. The model itself should not need to move around. You may have several views on the same model which would make your current implementation impractical.

Crag_Hack

@SGaist OK right now I do have the model creation in a worker thread and can move the tree traversal there easily as well. I thought I needed to use moveToThread() and a signal/slot for the model to move it to the GUI thread in order to use it for a QTreeView. See here for a related thread.

Crag_Hack

@SGaist How do I use the model from a worker thread without using moveToThread() and a signal slot connection then? Thx

SGaist

@Crag_Hack said in Moving QAbstractItemModel Subclass Instance from Main GUI Thread to Worker Thread When Used in a QTreeView:

@SGaist How do I use the model from a worker thread without using moveToThread() and a signal slot connection then? Thx

My suggestion is to do things the other way around: the model uses a separate thread for the heavy lifting.

Crag_Hack

@SGaist said in Moving QAbstractItemModel Subclass Instance from Main GUI Thread to Worker Thread When Used in a QTreeView:

My suggestion is to do things the other way around: the model uses a separate thread for the heavy lifting.

That's what I'm doing now... create the model in a worker thread for heavy lifting, pass to GUI thread for the QTreeView, have the user interact with it, then send it back to the worker thread for processing (tree traversal) to interpret the interactions. Am I confused as to what you are suggesting? If so could you elaborate?

SGaist

No it's not.

My suggestion is that your model manages the thread. It does not move between threads.

Take a look at the implementation of QFileSystemModel for inspiration.

Crag_Hack

Will my current way of doing things suffice? I might be in a little over my head. I can take a peak at QFileSystemModel however I've had trouble interpreting Qt source code before.

SGaist

Suffice, you'll have to check but moving back and forth your model at any moment will likely create issues in the long run.

Crag_Hack

What kinda issues in the long run? No race conditions right?

Crag_Hack

Forgot to mention I am signal/slotting pointers to the models not objects themselves... race condition possible? Do I need to mutex the model? Does this approach work well? Does this make more sense were you guys under the interpretation that I was signal/slotting objects? Thanks

SGaist

Can you explain your model design ?

You just explained that you are moving pointer to objects around one or more models (it was only one until now but you used plural in your last message) that you move from one thread to another.

Crag_Hack

@SGaist Thanks I am using 5 different tree models and 5 different QTreeViews, one model per view, thus the original statement about only one instance. I dusted off my Computer Systems book from college and reread the concurrency chapter; I'm pretty sure race conditions aren't and issue but I'm by no means an expert. I posted some code below. The Worker object lives in a worker thread for long-lived operations. The Program object is the main program object living in the main GUI thread to handle all GUI display. Any input would be much appreciated.

void Worker::createModels()
{
    TreeModel *treeFilesModel = new TreeModel();
    //other 4 models created after this

    //code here to add items to the models

    treeFilesModel->moveToThread(QApplication::instance()->thread());
    //other 4 models moved to main GUI thread
    emit passModels(treeFilesModel,...other 4 models); //signal to move models to main GUI thread for display, target slot is passModelsAndSetupTree
}

void Program::passModelsAndSetupTree(TreeModel *treeFilesModel,...other 4 models)
{
    treeFilesView = new TreeView();
    treeFilesView->setModel(treeFilesModel);
    //other 4 views set up
    //after everybody is set up user can interact with views to choose actions on model items displayed in views
}

void Program::traverseTrees()
{
    traverseTree(treeFilesModel->getFirstItem());
    //other 4 models traversed

    //should I delete the treeviews here?
    //should I move models to worker thread here using moveToThread()?

    emit process(treeFilesModel,...other 4 models); //signal to move models to worker thread for processing
}

SGaist

I insist, stop moving your models around. There should be no need for that.

The name of your model variables makes it look like you are implementing your own QFileSystemModel, is that the case ?

Crag_Hack

@SGaist said in Moving QAbstractItemModel Subclass Instance from Main GUI Thread to Worker Thread When Used in a QTreeView:

I insist, stop moving your models around. There should be no need for that.

So get rid of moveToThread() calls but leave signal/slots (obviously) right? If so we should update the other thread since I was told to use those calls there.

The name of your model variables makes it look like you are implementing your own QFileSystemModel, is that the case ?

I made the models from scratch borrowing code from this book. I never looked at how QFileSystemModel was constructed to influence my own models.

SGaist

Indeed, keep the signals and slots and stop moving your model around. Note that you can make use of threads within your model. Just that it does not make sense to move your model itself back and forth between threads.

That's a very good book.