[Qt-interest] QThread vs QTimer for polling

[Mandeep Sandhu]

On Sat, Feb 27, 2010 at 9:37 PM, David Boosalis
<david.boosalis at gmail.com> wrote:
> How are you getting notification of the harware's state.  If your reading a

I'm using a 3rd party library which queries the h/w for the status of
the last command issued to it.

This device is not something std, i.e it's not connected to the host
via a serial port etc, rather it's a subsystem which is part of a SoC.

> 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.

I had thought of of DBUS (using QDBUS), but it looked too much for
just relaying info that only my program wants. No other app in my
system is interested in knowing these events.

>
> 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().
>

Another thing I found was that, using the 3rd party lib, I could get a
file handle representing the device to be queried. So I setup a
QSocketNotifier to monitor events on this FD. Whenever I get an event
notification, I could query the h/w for status. But the problem is
that the moment I enable the notifier, i get a barrage of events
continuously on this FD. And I have to sift through the returned
status to see if the event I'm expecting is there or not (there's no
way currently of instructing the h/w of giving me back only specific
info).

So basically, in this approach, I have to ignore stuff in which I'm
not interested. Though I'm a little worried about the overhead of the
notifier callback happening so frequently (to reduce load on the CPU,
I'll be disabling the notifier when I get the status result and enable
it again when the app issues another cmd).

>
>
>
> 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.

Thanks for the many suggestions.

Regards,
-mandeep

>
> -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
>
>