[Qt-interest] QThread vs QTimer for polling

[Mandeep Sandhu]

Hi All,

I'm using Qt on an embedded platform.

My application is required to poll a particular h/w component for
status changes/monitoring. Basically my application wants to get the
status of a certain commands given to the h/w (these commands don't
have immediate effect and hence the need for polling). Polling must be
done till the time the requested status is achieved OR the maximum
number of retires have been exceeded. Once the app gets the status, no
more polling is needed till it issues another command.

I can think of 2 ways of achieving this:

* QThread: Start a thread to monitor the h/w status changes and inform
my application using signals. This thread is started in the beginning
and runs forever, till explicitly stopped by the application. When the
application has not requested for polling, it simply sleeps (on maybe,
a semaphore or some wait condition).

* Qtimer: Start a single-shot timer when polling is needed. Each time
the timer function runs, it checks the status requested, if it's met,
it signals the app, else it fires another single-shot timer and checks
again later.

My question is that which one of these approaches has better
performance, considering I'm running in an embedded environment and
would like to load the CPU as little as needed. Or maybe there's a
third approach? Is firing a timer repeatedly more "expensive" (in
terms of CPU cycles) than say waking up a thread (at similar
intervals)?

Any suggestions?

Thanks,
-mandeep