How to delete tied objects in Qt? - c++

Question

There are two classes: Widget and Worker. Here is a schematic code.
class Widget
{
Worker *m_worker;
QTextEdit *m_edit;
public:
Widget():m_edit(new QTextEdit){}
~Widget()
{
m_worker->ShouldStop = true;
delete *m_worker;
}
void doWork()
{
m_worker = new Worker;
if (!worker->doWork())
m_edit->setText("failed");
}
}
class Worker
{
Worker() : ShouldStop(false){}
public:
bool ShouldStop;
bool doWork()
{
while(true && !ShouldStop)
{
QThread::sleep(1);
QApplication::processEvents();
}
//consider the work undone if a stop was forced
if (ShouldStop)
return false;
}
}
After a call to doWork() of the Widget the execution loops in the method doWork() of the Worker. A widget is then closed and its destructor is called during one of the calls to processEvents(). Then the execution then returns to the doWork() of the Worker.
It now checks ShouldStop and returns to the doWork() of the Widget and tries to add something to the m_edit. However the Widget object is already dead.
Questions:
How can a Worker be deleted cleanly?
What is the best design to avoid such an interplay?

Answer 1

Ideally, worker threads should just return data via the signals and slots mechanism, not directly accessing the original object. Actually creating a thread and avoiding the call to QApplication::processEvents() is the first way to avoid the problem.
Additionally, you should consider using a design like this when you want to start a worker in a new thread. Rather than subclassing QThread, you can just create a generic QThread and assign a QObject to it, like so:
Worker *worker = new Worker;
QThread *workerThread = new QThread(this);
connect(workerThread, &QThread::started, worker, &Worker::doWork);
connect(workerThread, &QThread::finished, worker, &Worker::deleteLater);
worker->moveToThread(workerThread);
// Starts an event loop, and emits workerThread->started()
workerThread->start();
Consider restructuring your code around this pattern if you're using Qt 5.

Answer 2

#Alex answer is definitely the way to go for q2. He just forgot to mention how to proceed for the deletion (q1). Assuming Widget created the object workerThread, then this is necessary:
~Widget(){
if(workerThread->isRunning()){
workerThread->terminate(); <--- this line, right there
workerThread->wait():
}
...
}
Why? Because deleting a QThread just delete the thread object but doesn't stop the thread from running, and may crash the application. Note that if you are using
connect(workerThread, &QThread::finished, worker, &Worker::deleteLater);
as Alex mentioned, then it is not safe to access worker after the call to terminate, because it will trigger the finished() signal ,execute worker->deleteLater, and eventually delete worker.

Answer 3

You could have Widget use a signal to inform the owner of Widget to start up Worker for the Widget.
Owner owns both Widget and Worker. Widget tells Owner that something was triggered, and Owner is responsible for deciding that Worker's doWork() is the correct response, and for managing the lifetime of both Worker and Widget. Worker and Widget are ignorant of each other, but Owner might connect some of their signals and slots together.