Hello,

I would like to understand how internally Qt triggers its QTimer "trigger" event. I'm on a Windows 7 platform (this may be important as timer implementation vaies from one platform to another).
I need to figure out what will happen in case the processing inside the QTimer slot is too long for the selected interval. As an example:

Qt Code: 
  1. QTimer timer;
  2.  
  3. timer.setTimerType(Qt::PreciseTimer);
  4. connect(&timer, SIGNAL(timeout()), this, SLOT(_processing()));	
  5. timer.start(1000);
To copy to clipboard, switch view to plain text mode 

Qt Code: 
  1. void MyClass:_processing(void)
  2. {
  3.    int timeout = 2000; // in msec
  4.    int result = read(Io_handle, &buffer, timeout);
  5. }
To copy to clipboard, switch view to plain text mode 

If the IO read succeeds, the processing time will be below one second, which is the QTimer interval, and therefore we didn't "miss" a QTimer event.
On the other side, if the read() goes in timeout, as the timeout is longer than the QTimer interval, what will happen from Qt point of view ?

Qt spec says that:
"All timer types may time out later than expected if the system is busy or unable to provide the requested accuracy. In such a case of timeout overrun, Qt will emit activated() only once, even if multiple timeouts have expired, and then will resume the original interval."

It is true that timer times out later, but it doesn't seem to be true that activated() is emitted only once, and that the original interval is resumed...

In your experience, did you actually see the Preicse Timer behaving as explained above ?
On my side I see some strange behavior with a code similar to the one above: it behaves as if activated() events were "queued", and after exiting a processing that exceeds timer interval, I can see sometimes many timer events executed in a row with no respect at all of the interval, but instead executed ASAP. Sorry, I can't post a working code for the moment because this is part of a large project.

Thanks in advance !