There are more than one approach for dealing with this issue:
1) Manual sleep and waking up at certain periods yourself to check if something is changed. This would be called polling by the jargon.
2) Use an event loop for your thread to process the events like signals and slots.
I would suggest the latter because the former may have the defect of literally not being able to do anything while sleeping and you may get it wrong. More importantly, you would also lose the great signal and slot mechanism all of a sudden, and your code would become somewhat more coupled than necessary.
As for doing the latter correctly, you would need to make sure to have the proper Qt event loop execution in place which is guaranteed by the later versions of QThread
. That being said, please read the following documentation as I think it is useful to be aware of:
int QThread::exec() [protected]
Enters the event loop and waits until exit() is called, returning the value that was passed to exit(). The value returned is 0 if exit() is called via quit().
This function is meant to be called from within run(). It is necessary to call this function to start event handling.
You could also accomplish an in-between third solution as well, eventually, by mixing the two aforementioned approaches, namely: call the method below to explicitly make sure all the events are getting processed. It would be a semi-(a)sync way (depending on how you look at it) since you would need to do that when waking up from the sleeping for polling, but rather than dealing with the polling manually, you could use this convenience method.
Processes all pending events for the calling thread according to the specified flags until there are no more events to process.
You can call this function occasionally when your program is busy performing a long operation (e.g. copying a file).
In the event that you are running a local loop which calls this function continuously, without an event loop, the DeferredDelete events will not be processed. This can affect the behaviour of widgets, e.g. QToolTip, that rely on DeferredDelete events to function properly. An alternative would be to call sendPostedEvents() from within that local loop.
Calling this function processes events only for the calling thread.