[Qt-interest] QThread vs QTimer for polling

[Andrew Hodgkinson]

On 01/03/2010 10:30, Mandeep Sandhu wrote:

> [ Thread or timer ]

I thought your original message was pretty clear and didn't reply because 
I've not looked into the exact (doubtless per-platform) overhead of the 
two constructs, however it seems to me that:

* In another thread about media playback it became apparent that QTimer
   delivery can be delayed by much more than you might expect when other
   parts of the UI are being updated. Provided you don't want to poll
   often and don't have only a very short time window in which you must
   detect the hardware status change, this might actually be desirable -
   the GUI in effect takes priority over the timer, which in an
   embedded device, is most likely what you want.

* If any of the conditions above are not true (e.g. you need to ensure
   the hardware is polled within a certain time limit) then you'll need
   to use a thread. The periodicity of repeated QTimer delivery in the
   main application thread is simply not sufficiently deterministic. Of
   course, two threads will always use more resources than one, even if
   one just sits there and is never invoked (context information must be
   stored somewhere). If your hardware timing is *really* sensitive then
   you're looking at a real-time programming problem and the solutions
   lie within the domain of your OS, not Qt.

* If there is an event-based mechanism which would avoid polling in the
   first place then using this would surely be the most CPU efficient
   solution.

A choice of a thread using QTimer or sleep may well depend on precisely 
now QTimer intervals are implemented for the port of Qt to your platform 
- it should be pretty easy to set up a test with a simple QTimer based 
thread vs a simple sleep based thread and compare CPU usage between the two.

-- 
Andrew Hodgkinson, Endurance Technology
Land line: 01223 369 408, mobile: 07855 866 780
Registered Office: 5 Marine Drive West, Bognor Regis, W. Sussex, PO21 2QA