Unsolved executing query after cloned connection is used in another thread
-
@christian-ehrlicher
yeah that's right. query executor should execute the query since it is in the new thread, so the code should be like this:void QueryThread::execute(const QString &query, const QHash<QString, QString> &mapBoundVals) { // forward the execution to the worker emit executefwd(query, mapBoundVals); } void QueryThread::run() { qDebug() << "started thread" << QThread::currentThreadId(); m_queryExecutor.setDatabase(m_sDbPath); connect( this, SIGNAL( executefwd( const QString&, const QHash<QString, QString> & ) ), m_queryExecutor, SLOT( execute( const QString&, const QHash<QString, QString> & ) ) ); // forward final signal connect(&m_queryExecutor, &queryExecutor::finished, this, &QueryThread::queryFinished); exec(); }
-
Your executor still lives in the main thread as it is created at your custom thread subclass creation time.
-
@sgaist
oh okay, so it should benew
ed in QueryThread::run() -
It can be on the stack. It really depends on how you want to implement that stuff. You seem to be mixing the worker object approach with the subclass QThread approach.
-
@sgaist
i followed this example for my implementation: https://www.linuxjournal.com/article/9602
but anyways i think thread is still not much helpful because my for loop still executes in main thread. am i right?bool doWork(const QString &newVal) { for (each of selected table rows) { if (!table->updateRow(row, newVal)) return false; } return true; } bool Table::updateRow(int row, const QString &newVal) { //update in another thread }
-
As already said, you are mixing two different technique the wrong way.
If you subclass QThread and re-implement
run
, then what is executed inrun
happens in the thread managed by QThread.However, you created an instance of your worker object in the original thread since it's part of your QThread subclass and thus the slot will be executed in the original thread.