Threads - stop/ resume
-
Hi, I created a class and add it to a new thread (this-> moveToThread (QThread *));
everything works nicely, I connected the signals of this class of functions that run in the main thread. I had to do that because the threads controls the labels that appear on the form. But I need also draw lots of labelów position. Initially, the draw takes place in the constructor, so before class will run in a separate thread. However, when the draw takes place when a thread already going on, something is not working properly. It seems to me that if they stop the thread and draw function to perform in the main thread if it would work around, however, I do not know how to stop the thread, thrown out of the class to perform the function and back to give this-> moveToThread (QThread *), thread-> start ();I use the label as a vehicles to simulate the intersection based on the right-hand rule. When the car reaches the end, the draw for starting positions and to take place again. Depending on the starting position rotates the image in the page, unfortunately the new draw, the images are not displayed correctly.
-
Hi,
How do you control the drawing? Paint events can only be handled in the main thread -- you can't draw anything from a secondary thread. You can use your new thread to calculate the POSITIONS of the car, but you need to send the position data back to the main thread for drawing.
By the way, have a look at the "Graphics View Framework":http://qt-project.org/doc/qt-4.8/graphicsview.html -- it might suit your use case better than QLabels
-
As for actually pausing/resuming threads, that can only be done via "QtConcurrent":http://qt-project.org/doc/qt-4.8/qtconcurrent.html . However, the implementation isn't very good, and the Qt developers are thinking of replacing it.
-
[quote author="JKSH" date="1358642073"]As for actually pausing/resuming threads, that can only be done via "QtConcurrent":http://qt-project.org/doc/qt-4.8/qtconcurrent.html . However, the implementation isn't very good, and the Qt developers are thinking of replacing it.[/quote]
Well actually he wouldn't need to pause the thread, he just needs to pause his worker object he moved to the thread. This can either be done by disconnecting the worker from all the relevant signals he receives, or by having another connection (e.g.: @ connect(objectInMainThread, SIGNAL(pauseWorkerRequested()), workerObjectInOtherThread, SLOT(pauseWorker()));@ ) that could set a flag in the worker object causing him to pause.
-
There was a blog post today from the Woboq team about correct thread usage:
http://woboq.com/blog/qthread-you-were-not-doing-so-wrong.html
This was the reference document for thread implementations done right earlier (which Olivier also is referencing in his blog post): http://blog.qt.digia.com/blog/2010/06/17/youre-doing-it-wrong/
Cheers,
Chris
-
[quote author="feldifux" date="1358884071"]There was a blog post today from the Woboq team about correct thread usage:
http://woboq.com/blog/qthread-you-were-not-doing-so-wrong.html
[/quote]I don't agree with the argumentation the author of the article mentioned by you above uses. Especially the example which is given. For the use cases he presents it would make much more sense to subclass QRunnable then to subclass QThread. In my opinion in the use cases where he says its ok to subclass QThread, QRunnable would actually be the first choice.
I'm not saying that there are no valid reasons for subclassing QThread, but in most cases you'd be better of using the worker object approach, even though it might be 10 lines of code more.
