JoeMerchant
17th July 2009, 17:04
Hi,
I have an app with a big, nicely functioning, GUI that I want to add some threaded processing to, using threads to draw things that take a long time, and since there may be multiple things that take a long time, multi-core systems should draw faster - I hope....
There are a few (like 3 to 8) of these widgets, each creating their own "DrawingThread" which runs the default event loop. When the widgets draw quickly, everything is fine, but if the drawing thread is taking a long time, the main GUI hangs, timers don't fire, etc. I have added "yieldCurrentThread()" into the worker function in the drawing thread, but that seems to do nothing. Adding msleep( 1000 ) causes the drawing thread to pause for 1 second, but the GUI remains hung during this pause. The worker function is a slot in the DrawingThread object and is fired by a signal emitted by the GUI. In turn, it fires periodic signals to slots (repaint()) in the GUI, and these are being done, but nothing else. So, I see my slow drawing screen slowly work across, while everything else is frozen... Once the drawing is done, everything is snappy again. To be clear, the GUI isn't sluggish, it's dead stopped. Setting the DrawingThread priority down doesn't do anything except cause my app to fall behind others in the system for priority - the GUI still stays hung.
I've read all about thread affinity, and as far as I can tell, this is it's own thread. I have other threads in the app where I re-implemented the run() and they all work as expected with the GUI continuing nicely while they work, they produce signals but do not consume them. This is my first thread to use the default run() {exec();}, and that seems to be the difference, due to the implementation, these threads need to receive signals....
It seems like I just have a fundamental implementation issue - any ideas what it might be?
Thanks,
I have an app with a big, nicely functioning, GUI that I want to add some threaded processing to, using threads to draw things that take a long time, and since there may be multiple things that take a long time, multi-core systems should draw faster - I hope....
There are a few (like 3 to 8) of these widgets, each creating their own "DrawingThread" which runs the default event loop. When the widgets draw quickly, everything is fine, but if the drawing thread is taking a long time, the main GUI hangs, timers don't fire, etc. I have added "yieldCurrentThread()" into the worker function in the drawing thread, but that seems to do nothing. Adding msleep( 1000 ) causes the drawing thread to pause for 1 second, but the GUI remains hung during this pause. The worker function is a slot in the DrawingThread object and is fired by a signal emitted by the GUI. In turn, it fires periodic signals to slots (repaint()) in the GUI, and these are being done, but nothing else. So, I see my slow drawing screen slowly work across, while everything else is frozen... Once the drawing is done, everything is snappy again. To be clear, the GUI isn't sluggish, it's dead stopped. Setting the DrawingThread priority down doesn't do anything except cause my app to fall behind others in the system for priority - the GUI still stays hung.
I've read all about thread affinity, and as far as I can tell, this is it's own thread. I have other threads in the app where I re-implemented the run() and they all work as expected with the GUI continuing nicely while they work, they produce signals but do not consume them. This is my first thread to use the default run() {exec();}, and that seems to be the difference, due to the implementation, these threads need to receive signals....
It seems like I just have a fundamental implementation issue - any ideas what it might be?
Thanks,