Re: [Interest] Heavily Commented Example: Simple Single Frontend with Two Backends

[Syam Krishnan]

On 10/22/2012 03:16 AM, d3fault wrote: On Oct 21, 2012 11:02 AM, "Bo Thorsen" <b...@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. regards, Syam

_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest