[Interest] Heavily Commented Example: Simple Single Frontend with Two Backends
Bo Thorsen
bo at fioniasoftware.dk
Mon Oct 22 07:27:45 CEST 2012
Den 22-10-2012 03:38, Syam Krishnan skrev:
> On 10/22/2012 03:16 AM, d3fault wrote:
>>
>> On Oct 21, 2012 11:02 AM, "Bo Thorsen" <bo at fioniasoftware.dk
>> <mailto:bo at fioniasoftware.dk>> wrote:
>> >
>> > If you set out to correct the documentation, you should make it better,
>> > not go from one one-sided way of thinking to another.
>> >
>>
>> What? Are we talking about the same thing? 99% of the time,
>> implementing QThread and overriding run() is not what the user wants
>> to do... but that's what the (currently being revised) documentation
>> suggests. Sure it's not completely wrong... but that method should be
>> just barely mentioned, and only after the better usage (moveToThread)
>> is thoroughly explained. There are too many people "doing it wrong"
>> (to quote that one article).
>>
>
> A question to all:
>
> I have a GUI application. I need to do some task (for example,
> periodically reading/writing from a serial port) in the background
> that has nothing to do with GUI. i.e. the background task does not
> touch GUI or need to emit signals or have slots. It just needs to be
> there, reading & writing to shared memory (protected by Mutex).
>
> Now, the way I've been doing this is by creating a new class from
> QThread and overriding run() to implement my thread function. The
> function is often a loop that runs till a public volatile bool
> variable is set, indicating time to quit. For doing periodic stuff, it
> sleeps for few milliseconds (by using nanosleep()). When the program
> is terminated, in main windows' close event, or some other suitable
> place, I set the thread loop control variable and wait for the thread
> to terminate (QThread::wait()).
>
> Is there any other recommended or better way to do it? Note that I
> don't need to do any Qt stuff (update GUI, signals & slots etc.) in my
> 'worker' thread.
There's nothing wrong with the way you use QThread. It's one of the
examples of when it's perfectly fine to use it by subclassing.
However, when somebody mentions volatile bools and shared memory, I get
ticks and start hearing 1980's music. If you want to improve something,
getting rid of this stuff is a much better candidate.
Bo Thorsen.
Come by my DevDays talk in Berlin - "Designing for testability". Learn how to build and run your unit tests with the Qt application.
Fionia Software - Qt experts for hire.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20121022/71e14178/attachment.html>
More information about the Interest
mailing list