ThreadedGUI

Minimum Requirements

While server manager/servers are busy:

• support repainting of GUI to look alive
• support minimizing, restoring, maximizing of GUI
• support exiting of application

Would-be-nice-to-have Requirements

• support interaction with non-busy servers (open another file on another server, view model in graphics window for non-busy server, etc...)

Possible solutions considered

1. One thread for GUI and one thread for server manager.
2. One thread for GUI and server manager, multiple threads, one for each server.
3. One thread for GUI and multiple threads, one for each server manager.
4. One thread for GUI, server manager, and all servers.

Threading issues and considerations

• Client side OpenGL may not support multiple threads. Which means render module(s) might need to be on GUI thread.
• Inter-server interactions get complicated by threading. Consider data comparison between two servers. A client side VTK filter can interact with reduced data on multiple servers.
• Threads don't play well with MPI.

Proposed Solution

Multithreading the server manager is basically not worth it. Solution #4 is suggested. The servers should be sending progress events back to the client at all times. The GUI client can use that time to update progress bars, respond to users minimizing, maximizing, repaints, etc... This means interaction with non-busy servers would not be supported. The graphics window during these times could actually paint something that shows the server manager is busy generating an image.