In an effort to create a Qt event loop in a separate thread, from within a DLL which is called by a main application written in Java, I have done the following, based on a suggestion I read here at http://stackoverflow.com/questions/2...qt-application, which works rather well:

Qt Code:
  1. // Define a global namespace. We need to do this because the parameters passed to QCoreApplication
  2. // must have a lifetime exceeding that of the QCoreApplication object
  3. namespace ToolThreadGlobal
  4. {
  5. static int argc = 1;
  6. static char * argv[] = { "MyVirtualMainApplication.exe", NULL };
  7. static QCoreApplication *coreApp = nullptr;
  8. static ToolThread *toolThread = nullptr;
  9. };
  10.  
  11. //! The ToolThread class differs from a standard QThread only in its run() method
  12. class ToolThread : public QThread
  13. {
  14. //! Override QThread's run() method so that it calls the QCoreApplication's exec() method
  15. //! rather than the QThread's own
  16. void run() { ToolThreadGlobal::coreApp -> exec(); }
  17. };
  18.  
  19. class ThreadStarter : public QObject
  20. {
  21. Q_OBJECT
  22.  
  23. public:
  24. //! Constructor
  25. ThreadStarter()
  26. {
  27. // Set up the tool thread:
  28. if (!ToolThreadGlobal::toolThread)
  29. {
  30. ToolThreadGlobal::toolThread = new ToolThread();
  31. connect(ToolThreadGlobal::toolThread, &ToolThread::started,
  32. this, &ThreadStarter::createApplication, Qt::DirectConnection);
  33. // The thread's 'started' event is emitted after the thread is started but
  34. // before its run() method is invoked. By arranging for the createApplication
  35. // subroutine to be called before run(), we ensure that the required QCoreApplication
  36. // object is instantiated *within the thread* before ToolThread's customised run()
  37. // method calls the application's exec() command.
  38. ToolThreadGlobal::toolThread->start();
  39. }
  40. }
  41.  
  42. //! Destructor
  43. ~ThreadStarter()
  44. {
  45. // Ensure that the thread and the QCoreApplication are cleanly shut down:
  46. ToolThreadGlobal::coreApp -> quit();
  47. delete ToolThreadGlobal::coreApp;
  48. ToolThreadGlobal::coreApp = nullptr;
  49. delete ToolThreadGlobal::toolThread;
  50. ToolThreadGlobal::toolThread = nullptr;
  51. }
  52.  
  53. //! Function to return a pointer to the actual tool thread:
  54. ToolThread* getThread() const { return ToolThreadGlobal::toolThread; }
  55.  
  56. private:
  57. //! Create the QCoreApplication that will provide the tool thread's event loop
  58. /*! This subroutine is intended to be called from the tool thread itself as soon
  59.   as the thread starts up.
  60.   */
  61. void createApplication()
  62. {
  63. // Start the QCoreApplication event loop, so long as no other Qt event loop
  64. // is already running
  65. if (QCoreApplication::instance() == NULL)
  66. {
  67. ToolThreadGlobal::coreApp = new QCoreApplication(ToolThreadGlobal::argc,
  68. ToolThreadGlobal::argv);
  69. }
  70. }
  71. };
To copy to clipboard, switch view to plain text mode 

To use this, a subroutine called from the main Java applications’ thread just needs to create a ThreadStarter object
which will automatically create a ToolThread with a QCoreApplication running inside it:

Qt Code:
  1. itsThreadStarter = new ThreadStarter();
  2. itsToolThread = itsThreadStarter -> getThread();
To copy to clipboard, switch view to plain text mode 

We can then instantiate a QObject class in the usual way, move it to the thread and call its methods asynchronously using QMetaObject::invokeMethod:

Qt Code:
  1. itsWorker = new Worker();
  2. itsWorker -> moveToThread(itsToolThread);
  3.  
  4. QMetaObject::invokeMethod(itsWorker, “doSomethingInteresting”);
To copy to clipboard, switch view to plain text mode 

When we’re done, we just delete the ThreadStarter object and everything is cleaned up nicely. Apart from the annoying message saying

WARNING: QApplication was not created in the main() thread

on startup, it seems to meet all my requirements.

Except… (and here, at last, is my question).

Occasionally - and without any pattern that I’ve been able to discern so far - I get an error during the shutdown process. Usually it occurs at the line

Qt Code:
  1. delete ToolThreadGlobal::coreApp;
To copy to clipboard, switch view to plain text mode 

but sometimes at the line

Qt Code:
  1. ToolThreadGlobal::coreApp -> exec();
To copy to clipboard, switch view to plain text mode 

(which of course is executed in the thread’s run() method and doesn’t return until after ToolThreadGlobal::coreApp -> quit(); has been fully executed).

Often the error message is a simple access violation; sometimes it’s a rather more involved:

ASSERT failure in QObjectPrivate::deleteChildren(): "isDeletingChildren already set, did this function recurse?", file ..\qtbase\src\corelib\kernel\qobject.cpp, line 1927

I assume it’s because, once I issue the quit() command to the QCoreApplication, I should be waiting for a little while for it to close down the event loop properly before deleting it - just as one would usually call quit() and then wait() on an ordinary QThread before deleting it. However, QCoreApplication doesn’t seem to have the equivalent of a wait() command, and I can’t implement a QTimer to force a delay because it wouldn’t work once I’ve closed down the event loop with quit(). I’m therefore at a loss what to do. I have an inkling that, as QCoreApplication is a QObject, I could call its deleteLater() method but I can’t see where I should call it from.

Is there an expert out there who understands the ins and outs of QCoreApplication and QThread well enough to suggest a solution to this? Or is there a fundamental flaw in the way that I have designed this?