Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am currently working with a Qt Application which tries to use multi threading to accomplish two task

  • To Prevent the Main Thread's Event Loop from being blocked
  • To increase computation efficiency

You would think it is a good idea, but it turns out that this might be inefficient. In Qt, the client is not permitted to instantiate a QWidget subclass only in the main thread.

The code I have seen so far seems really messy. The program has a "executive thread", in other words a background thread that manages user request (ie button click for a new gui panel), and of course there are 3 other thread (networking, script processing, and ofcourse the Main Thread)

The setup is kind of funky to say the least, the action event (ie Button Click) is signaled to the executive thread, which then sends a functor to the main thread to instantiate the user requested gui panel.

The above described make no sense. I am guessing that the original designers were concerned about the thread being blocked, but that shouldn't matter. Regardless of what thread instantiated in, it still ends up back in the main thread, and blocking it anyway.

This might not the be the best design choice, or is it? I am not sure, maybe there is someone here more experience that can shed light on this. I personally think it would be better to let one thread handle all user interaction, and any intensive user processing should can be threaded.

The other threaded parts make sense, having a seperate thread for processing scripts, networking actually could increase efficiency, while not blocking the main event loop so the gui can remain interactive.

Also could some one also elaborate on when Multithreading is a good choice in GUI, and in regular circumstances?

Thanks

share|improve this question
add comment

2 Answers

Typically I use threads for work displayed by a GUI, not for handling the GUI itself. Otherwise all sorts of problems like you have here pop up.

You realize this in this quote "I personally think it would be better to let one thread handle all user interaction, and any intensive user processing should can be threaded." and I believe that is the way you should take this.

The GUI thread will use proxies whose job is to mediate between GUI stuff and asynchronous results coming from worker thread(s). Your proxy can immediately create the GUI elements while providing a temporary display of "working..." or something similar while waiting for the worker thread it's representing to finish and pass over the data.

I don't have a handy answer to threading GUIs, it sounds like a complex problem and I don't have experience using a system like that.

share|improve this answer
    
I guess the real question I meant to ask was, does it make sense to use a separate thread to handle an action of a button which creates a new window? Since GUI can only be created in the main thread, I don't think it makes much sense to have another thread to do some unwanted delegation. –  Anonymous Mar 15 '12 at 15:32
    
@Anonymous I think you are right. The new window could be responsible for threading off work done on its contents but should not itself be on any other threads. That's a very clean break and easy to document and maintain. –  Patrick Hughes Mar 15 '12 at 20:12
add comment

Also could some one also elaborate on when Multithreading is a good choice in GUI, and in regular circumstances?

In stock market applications (and other real-time applications) you may need more than 1 thread. You have 1 thread for user input, output and another that updates scrolling ribbons or progress bars on the GUI, and probably a third that updates graphical charts with streamed data. However, I guess it is not a common practice to have more than 1 thread for the GUI as this post suggests: stovf-threading.

share|improve this answer
    
+1 for the example, but I guess even in such kind of application it will be good idea to keep it to one non-blcking GUI thread, while background threads do the real-time data gathering and send the data to be displayed (for example, in a background chart) to the GUI thread by events. –  Doc Brown Mar 10 '12 at 10:35
    
Thank you for your comment, but I guess you still may want to have a dedicated thread for each open window. –  Emmad Kareem Mar 10 '12 at 11:24
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.