Cleaning up after a thread correcly

andre

I would not call deleteLater on a QThread that is still running. Sounds like a recipe for all kinds of funny things to happen when you don't expect it.

Edit:
What might be a good approach, is something like this:
@
connect(myThread, SIGNAL(finished()), myThread, SLOT(deleteLater()));
myThread->stopThisThread();
myThread = 0;
@

Franzk

[quote author="Andre" date="1307457203"]I would not call deleteLater on a QThread that is still running. Sounds like a recipe for all kinds of funny things to happen when you don't expect it.[/quote]

Neither would I. I was referring to what I've stated earlier:
@connect(myThread, SIGNAL(finished()), myThread, SLOT(deleteLater()));@

Edit: My point exactly :P

andre

Ah, sorry, missed your previous suggestion for the same idea. I would put the connect call before the stop call though. Otherwise, you might get into a race condition where the thread is already stopped before the connection has been made. Then again, you should probably make the connection at creation time for the thread anyway, not when you want to stop it.

giesbert

[quote author="Andre" date="1307457203"]I would not call deleteLater on a QThread that is still running. Sounds like a recipe for all kinds of funny things to happen when you don't expect it.

Edit:
What might be a good approach, is something like this:
@
connect(myThread, SIGNAL(finished()), myThread, SLOT(deleteLater()));
myThread->stopThisThread();
myThread = 0;
@

[/quote]

This can also lead to unexpected behavior. You call delete in the main thread when the event loop comes to this point. While it reaches this, the thread could be suspended (depends on timing) or be finished, even if the emit is the last command in the run method.

EDIT:

So you would need a wait in the destructor of the thread….

andre

Gerolf, you mean that QThread::finished() may be emitted before the thread is actually finished? That would be a bug, would it not?

Franzk

From reading the QThread sources it seems on symbian, the finished() signal is emitted from the threaded function (after run() returns). On unix, the signal is emitted in the pthread cleanup handler. Didn't check the windows code. It seems Gerolf could have a point here. However, if that is the case, the only way to check if the thread is actually still running is by using some pthread_kill() magic.

giesbert

[quote author="Andre" date="1307457823"]Gerolf, you mean that QThread::finished() may be emitted before the thread is actually finished? That would be a bug, would it not?[/quote]

The point is: when is a thread finished?

To emit a signal, you need code. This code is somewhere :-) If it is inside the threads function (even it is outside run()) you might get in timing problems.

andre

I get that, and judging by Franzks analysis, you have a point at least in the Symbian case. It seems logical to me that Qts implementation would make sure the thread really has terminated before the signal is emitted. I understand that you need code to do the emit, but that code does not belong in the thread who's termination it is supposed to signal. That would mean that the Symbian implementation is wrong, but I have no idea if it is possible to do it the right way on that platform.

giesbert

I even don't know if that is possible on windows.
But the Qt code does not guarantee that.
This is an excerpt of QThread for windows:

@
unsigned int __stdcall QThreadPrivate::start(void *arg)
{
// some initialization

emit thr->started();

thr->run();

finish(arg);
return 0;

}

void QThreadPrivate::finish(void *arg, bool lockAnyway)
{
// some other stuff
emit thr->finished();
// some other stuff
}

void QThread::start(Priority priority)
{
// some other stuff
d->handle = (Qt::HANDLE) _beginthreadex(NULL, d->stackSize, QThreadPrivate::start,
this, CREATE_SUSPENDED, &(d->id));

// some other stuff

}
@

This means, the thread function QThreadPrivate::start defines the thread. When it is finished, the thread dies. Within this method, the finished signal is emitted and it is not at the very end of the thread, but guaranteed after the run method....

I'm not sure, whether there is a thread stopped signal on windows...

Franzk

Apparently the windows thread performs exactly the same action as the symbian implementation. The linux implementation does pretty much the same when no pthread_cancel() is used. The cleanup function is called by a pthread_cleanup_pop(1); This is likely to happen within the thread though. Anyway, this being known, the solution would rather go towards

@connect(t, SIGNAL(finished()), this, SLOT(cleanupThread()));
...
void This::cleanupThread()
{
thread->wait();
thread->deleteLater();
}@
provided of course that wait() is guaranteed to wait until the OS thread is actually finished. Details are different, but the general idea is still the same.

giesbert

This should work.
wait uses the variables that are set by the finished method before the signal finished is emitted, but there is a mutex around both functions. So wait should return when the thread is really finished.

andre

I still think it is a bug in Qt then. Qt could use the same trick itself to make sure finished() is emitted after the thread has really terminated, could it not?

giesbert

I can't. Otherwise it would need another thread to wait for this one :-)

It can't use the main thread, or has to send an internal event to the QThread object which then would have to block the QThreads creator thread untill the real thread is destroyed and then emit the signal.... not very nice....

but just calling wait in the slot for the finished signal would do the trick.

andre

The wait time would be very short, if there at all. After all, the thread is supposed to be done, right? Now, you have to wait in the main thread anyway. Why not give that task to QThread instead? The real thread could (in absense of a signal from the OS), as it's last act, indeed just send an event to the QThread and then terminate. The QThread object could in its handler for that event wait for the thread to be finished, and only then emit the signal. I like it more than having to code constructions like these:

@
connect(t, SIGNAL(finished()), this, SLOT(cleanupThread()));
...
void This::cleanupThread()
{
thread->wait();
thread->deleteLater();
}
@

You have gained nothing (still waiting for the thread) and you have to write additional code.

Franzk

[quote author="Andre" date="1307523633"]You have gained nothing (still waiting for the thread) and you have to write additional code. [/quote]
That is not entirely true. What you have gained is a non-blocking solution to the thread cleanup, because the thread is cleaned up at a point where you know for sure that QThread::wait() isn't going to last for more than a few milliseconds.

andre

Considder this class then:

@
FixedQThread: public QThread
{
Q_OBJECT

public:

FixedQThread(QObject* parent = 0)
: QThread(parent) {
    connect(this, SIGNAL(finished()), SLOT(waitForReallyFinished()));
}

signals:
void reallyFinished();

private slots:
void waitForReallyFinished()
{
wait();
emit reallyFinished();
}
};
@

After which you can do:
@
//thread of type FixedQThread now:
connect(thread, SIGNAL(reallyFinished()), thread, SLOT(deleteLater()));
@

Right?

Franzk

Aye, that ought to work. It's basically the approach mentioned earlier, just wrapped in a class, which is a good thing to do anyway.

andre

So... Why could that same approach not be inside QThread instead?

Franzk

That would be too obvious, wouldn't it?

andre

Which I why I stated that I think that QThread should be fixed to always emit the finished signal after the thread has actually finished. It is not like it would be very hard to do, as demonstrated above...

Edit:
Actually, I guess even wait is not going to save the day. See "this bug report":http://bugreports.qt.nokia.com/browse/QTBUG-684 . I have filed a "bugreport":http://bugreports.qt.nokia.com/browse/QTBUG-19783 on the issue.

QtWS: Super Early Bird Tickets Available!

Cleaning up after a thread correcly