I have a classic calculation-intensive GUI application where calculations needed to keep the GUI up-to-date are performed in a separate QThread, passing the results back to the GUI for display when ready via the signals-and-slots mechanism. The 'run' function within the QThread passes most of the calculations on to a separate DLL, written in Fortran, which does the actual number-crunching. The Fortran DLL routines, in turn, are parallelised using OpenMP.

If I compile my Fortran code with the Intel compiler, this works fine. However, I have been evaluating another Fortran compiler which, when it works, runs about three times as fast. However, it often crashes when entering an OpenMP section, and the compiler vendor tells me that it's because it's unhappy trying to set up the OpenMP thread team from within what is already a sub-thread of the main application. They suggest having the "main" thread doing the calculations while a sub-thread operates the GUI.

Is this possible using Qt? I guess that the thread used for the GUI is determined in the "main" routine:

Qt Code: 
  1. QApplication a(argc, argv);
  2.     MainWindow w;
  3.     w.show();
  4.     return a.exec();
To copy to clipboard, switch view to plain text mode 

...and its not obvious to me how I would either farm "w.show" out to a different thread or assign any other QObject to the main event loop.

Is there, in fact, a way of doing this?

Thanks,
Stephen.