[Qt-interest] Controlling when timers run

[Jeroen De Wachter]

Could you maybe explain your need to use timers in the first place? Are
these things that need to run every x milliseconds no matter what? Or
only in some circumstances?
We might be able to suggest alternative approaches...

One thing you could do, regardless of your use case for timers, is to
use NonRecursive QMutexes when you try to access sensitive data. Lock
the QMutex in the non-QTimer code, then use QMutex::trylock() in the
QTimer code to see if it's ok to use the data. tryLock() will ensure you
don't end up with a deadlock. This way, it doesn't matter if the event
loop is processed while your non-QTimer code is still running. It may
seem a little strange using a QMutex in a single-threaded application,
but it should work.
This solution does require the programmers to lock the mutexes though,
so that may be too inconvenient for you (unless you can find a way to
lock it for them)
You should also be very careful not to try to lock the QMutex
recursively (I don't know what your program flow looks like). It may be
better to just use tryLock() everywhere (and check the return status!),
just to be safe...

Another method that might be of use to you, but only if you don't really
need the function to be called every so often, but only at some points
in time, may be to emit an Asynchronous (flag to the connect() call)
signal when you need the (what is now your QTimer) code to run at *some*
point in the near future. This way, processing of the timer code only
happens when the signal has been posted to the event loop and will run
whenever processEvents() is called.

Kind regards,

Jeroen De Wachter

On Thu, 2010-01-14 at 23:41 +0000, Sean Harmer wrote:
> Hi,
> 
> Glenn Hughes wrote:
> > Hi Sean, yes, that helps, 
> 
> OK good at least that solves at least some of the problems.
> 
> > but I'd like a way of doing this so that the
> > programmer does not need to remember to do the
> > TimerManager::instance()->stopTimers(); /
> > TimerManager::instance()->startTimers(); around each call to exec.
> > The
> > more stuff like that the programmer needs to do the less likely they
> > will remember to do them, and the more likely bugs will sneak in.
> 
> Well, you could derive your own base class for dialogs that does it for 
> you when you call exec() to make this less cumbersome for the 
> programmers. All they have to remember to do then is to derive their 
> dialogs from your custom class rather than directly from QDialog.
> 
> If this is still too onerous an undertaking then you could look at 
> moving your timer driven processing into a separate worker thread as 
> then you will only have a single event loop in that thread. However, you 
> would then need some kind of synchronisation with the main GUI thread as 
> to when processing can be done.
> 
> > Thanks!
> 
> You're welcome.
> 
> All the best,
> 
> Sean
> _______________________________________________
> 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.