Hi,

I found an interessting behaviour in QTimer that I believe is in contradiction to what the documentation says. It seems like QTimer is racing to make up for lost timer ticks instead of discarding them.

My system has 2 threads. Thread 1 is responsible for the communication and uses a 100ms timer to send and receive data from a microcontroller. Thread 2 does the heavy processing that take up to several seconds. If now Thread 2 uses all CPU time for it's processing Thread 1 should afterwards continue to send/receive every 100ms even if some timer ticks were lost due to the CPU being unavailable. This is also what the documentation of QTimer says:

"Timers will never time out earlier [...].
If Qt is unable to deliver the requested number of timer clicks, it will silently discard some."

On my system this is not the case. I am seeing timer ticks emitted every 20-30ms for some time after the heavy processing until the rate stabilizes again at the nominal 100ms. It seems like QTimer is trying to make up for the lost timer ticks.

I found a workaround though that I can recommend if anybody has a similar issue. Instead of using a QTimer I am now using a forever-loop that calls the send/receive method and uses msleep() for the 100ms delay. On my embedded linux platform that works.

What is your take on this? Did I miss any configuration options on QTimer? Anybody had the same problem before?