[Qt-interest] QThread vs QTimer for polling

[David Boosalis]

How are you getting notification of the harware's state.  If your reading a
file you could look at QFileSystemWatcher, which will give you a
notification of when a particular file changed.  If the hareware device is
on a serial port you can do a thread or a process (fork) which simply reads
the device and sends a signal when there is a new read.  Another option if
you are on Linux is to look at DBus and QDBus.  If your looking for
something like a memory stick being plugged or unplugged this will handle
it.

Another idea that comes to mind is to create a Class that inherits from
QObject and use its virtual QObject::timeEvent() method at an interval
specified by QObject::startTimer(int).  This object you can put in its own
thread, or better yet since QThread inherits from QObject make this the base
class of your Special polling class and implement MyThread::timerEvent().




The thread way will not very much in the way of cpu resources if you run it
with its own eventloop, (in QThread:;run() you implement an exec() call.

Hope this is of some value to you.

-David



On Fri, Feb 26, 2010 at 11:45 PM, Mandeep Sandhu <
mandeepsandhu.chd at gmail.com> wrote:

> 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
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100227/3ce98a2f/attachment.html