QThread - how to stop worker? - c++

Question

I'm reading that I should use worker object and move it to thread by moveToThread instead of inherit from QThread directly. But I can't find solution how to stop loop in my object worker. For example I have test loop:
void CollectionWorker::doWork()
{
for (int i = 0; i < 10; ++i) {
sleep(1);
emit ping(i);
}
}
Now I'm moving this object to thread:
worker->moveToThread(mTh);
This is working fine. But when I call mTh.quit() then thread is waiting until loop in doWork is end. When I inherit from QThread directly then on each loop I can check thread status and break loop when thred is finished but don't know how to do it in worker object. Can I just create some flag in worker object and switch it from main thread? Or maybe can I find thread owner and check it status? Or maybe better before starting thread, set thread pointer in worker object and then check status? What is the best thread safe solution?
Regards

Answer 1

Calling quit() or exit() on a thread object will simply end the event loop of the thread if there is any running. But As you rightly pointed out, the original problem remains the same. What if the worker function has already been executed by event loop and is a long running function with forever construct. The call to quit() or exit() will simply wait till the worker function returns.
Couple of approaches can be suggested apart from making a public function available to caller which will alter an internal flag.
Give a termination signal and slot in your worker class. Something as following.
signals:
void signalTermination();
public slots:
void setTerminationFlag();
private:
QMutex mutex;
bool terminationRequested;
Your slot would look like something.
void setTerminationFlag()
{
QMutexLocker locker(&mutex);
terminationRequested = true;
}
Then you can check the variable in your doWork function in every iteration of forever loop.
mutex.lock();
if(terminationRequested)
{
//break from loop and effectively doWork function
}
mutex.unlock();
One of the reason of using signals and slots instead of plain member function is that, if your worker function is doing some long running task inside synchronized code block, the public function will remain blocked until it gets access of the synchronization object. This might have adverse effect if the calling thread of your public termination method is UI thread.
Another clean and simpler approach if you are using Qt 5.2 onwards
Use requestInterruption() method of QThread. This method sets an advisory flag in the thread object which you can check via isInterruptionRequested() function call in your doWork() function. See following code snippet given in QThread::isInterruptionRequested documentation.
void long_task() {
forever {
if ( QThread::currentThread()->isInterruptionRequested() ) {
return;
}
}
}
You can also directly call quit() here to end the event loop of the thread.

Answer 2

Edit: Sorry i've misunderstood your question.
There are several alternatives. You can create some flag and before each iteration of your processing loop you check if the flag has been set. Or, in the case your processing data in a list/queue maybe you could signal the process to terminate with a special end-of-data element.

Answer 3

I have the same problem as Dibo had. I'm running a long calculation loop inside my doWork() function and need to be able to stop it from my main thread.
Chadick Robbert's answers didn't do the trick for me. The first suggestion behaved just like what he describes for member functions. That is, although we're using signals and slots, calling setTerminationFlag slot from a signal emitted in the main thread, properly connected to it, only gets executed after the loop ends. But maybe I did something wrong with the implementation. If it really is supposed to work please let me know, because it seems like the deal breaker.
His second alternative of using QThread::currentThread()->isInterruptionRequested() to tell the thread to stop would work great if it weren't for the fact that you can't reset this flag if you plan on reusing the thread and worker for some similar processing intensive loop, if not the same. Surely you can get it done by stopping and starting the thread, but I'm not sure if it wouldn't have adverse effects like clearing execution queues on it. This issue was actually posted as a bug report and Thiago Macieira (key developer for Qt) mentions there, if I may quote him:
The purpose of the requestInterruption function is to finish the thread.
Which makes requestInterruption inadequate for the job, as it is reset only on thread start and finish.
A solution that I found, that doesn't seem all that clean to me, is to include QCoreApplication in the worker class and call QCoreApplicaton::processEvents() from time to time, to process those queued signals in Chadick Robbert's first suggestion or update the worker's class awareness of flag variables shared between threads.
Because calling QCoreApplicaton::processEvents() within your loop can slow it dramatically what I do is something like:
for(unsigned long int i=0; i<800000000 && !*stop; i++){
f += (double)i * .001; // dummy calculation
if(i%10000000 == 0) // Call it only from time to time
QCoreApplication::processEvents(); // update *stop according to main Thread
}
As you can see, with this solution the loop will only break at integer multiples of '10000000' which may not be adequate for some use cases.
If anyone knows of a killer solution to this I'd love to hear.

Answer 4

The idiomatic way in Qt to destroy a worker thread is using the signal/slot interface:
CollectionWorker *worker = new CollectionWorker;
QThread *workerThread = new QThread(this);
connect(workerThread, SIGNAL(started()), worker, SLOT(doWork()));
connect(workerThread, SIGNAL(finished()), worker, SLOT(deleteLater()));
worker->moveToThread(workerThread);
In order for this to work CollectionWorker must inherit from a QObject class and declare the Q_OBJECT macro.