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?