[Qt-interest] QThread vs QTimer for polling

[Mandeep Sandhu]

On Mon, Mar 1, 2010 at 4:39 PM, Andrew Hodgkinson
<ahodgkinson at endurancetech.co.uk> wrote:
> 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.

My timing requirement is fairly lenient and when my app is running
it's the only GUI component visible. However, there are other
system-wide events happening which are being monitored using DBUS. If
that does not screw-up the timer's predictability too much then I
guess I'm ok.
>
> * 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.

I'm exploring this option. As mentioned earlier, the 3rd party lib
does provide me with a FD for this device. BUT. The moment I connect
my QSocketNotifier to it, I get a _storm_ of events! :( I have to sift
through it to find out the stuff I'm interested in. Also I'm not very
comfortable with the fact that all these notifications are going to be
processed in Qt's main event loop (might cause problems elsewhere?
dunno).
>
> 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.

Ok. Will try and setup some tests towards that.

Thanks,
-mandeep

>
> --
> 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
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>