[Qt-interest] Proper way to terminate QThreads

[BRM]

Thanks for the one example - and while true that would work in that example, how does it work when each thread has its own Event Loop?

All my threads execute exec() in their run() - they all use the event loop; that's the only way to get the signals/slots going and fully working - which is one of things I am highly interested in.

Ben



----- Original Message ----
From: Jeroen De Wachter <jeroen.dewachter at barco.com>
To: BRM <bm_witness at yahoo.com>
Cc: qt-interest at trolltech.com
Sent: Tue, November 17, 2009 12:36:48 PM
Subject: Re: [Qt-interest] Proper way to terminate QThreads

Hey Ben,

You are right, you should not forcefully terminate a thread if there is
any other option. Otherwise, that thread may leave your application in
an unsafe state (it may still own some Mutexes that will not be
released, for instance), causing havoc/deadlocks in other parts of your
application.

I usually try to avoid the use of exit and terminate altogether.
The use of a boolean flag inside your thread to indicate if it should
still be running is quite common, I think.

Presumably you have a loop running in your network thread, so you could
check that boolean variable from time to time.

bool m_continue = true;

MyThread::run()
{
    while (m_continue)
    {
        readFromSocket();
        processData();
        ...
    }
}

MyThread::stop()
{
    m_continue = false;
    join();
}

the stop-method sets the boolean flag to false, which will ensure the
while-loop in the thread stops at the next iteration. The join call will
block and wait for the run method to return and the thread to stop, so
you know you can safely destroy the thread object afterwards. (you could
also just do this in your destructor if you like)

There are a lot of variations on this approach and a lot more complex
mechanisms as well (waiting for a QCondition while there is no work
tends to keep me on my toes with regard to shutting down a thread
cleanly), but you should be able to start with that.

Also: you'll probably want to specify a timeout on operations that will
block (like reading from a socket), so you don't end up waiting for
something that may never come.
Likewise, you may want to specify a timeout on that join operation, and
print some debugging info if it fails, so you get a heads-up if your
thread still blocks.

Kind regards,

Jeroen

On Tue, 2009-11-17 at 09:19 -0800, BRM wrote:
> I have several programs in which I am using QThread derived objects to do some working, mostly handling network connections. The basic structure is as follows:
> 
> myThread - derived from QThread
> myThreadInstance - class that does the work; instantiated via myThread::run()
> 
> myThread is pretty much just a signals, with myThreadInstance having signals and slots.
> The main program starts the thread using myThread->start().
> 
> I am presently having a small issue with one program that handles network connections using this threading setup - I receive a network connection from a QTcpServer instance and hand it off to a thread to manage. However, I need to cancel the thread when the connection goes away after I notify the main thread (so that it can initiate the cancel).
> 
> What is the proper way to cancel the thread?
> 
> I've noticed in the documentation that there is QThread::quit() and QThread::terminate(); however, I thought I remember reading somewhere that those should only be called from within the thread being terminated - not from a parent thread.
> What's the proper method for stopping these threads?
> 
> Thanks!
> 
> Ben
> 
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest


DISCLAIMER:
Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. Thank you.