Question

I am trying to use Qt as a library (similar to this), because I want to reuse Qt classes in some currently non-Qt applications, and in shared libraries as cross-platform glue. Everything is non-GUI.

Some problems are easily avoided by DirectConnection, some can be solved with private event loops, even one can run a fake QCoreApplication in a thread and it works (last resort).

I want to know what modules rely on a running instance of QCoreApplication and cannot work without it.

Some of the Qt modules (in QtCore) do need an instance of QCoreApplication to run properly. For example QTimer relies on QCoreApplication to dispatch timer events.
I was reading the documentation for QtConcurrentRun and it seems to be relying on a global instance of QThreadPool, I am about to try and see if the application execution is vital, or maybe the instance is created on first access, or maybe not.

I am going to study QCoreApplicationPrivate source (Windows and Linux for now) but any hints in the right direction is greatly appreciated.

What are other functionality dependencies to the core application? Note that it might depend on the OS.

Edit1: Thanks to Kuba’s answer, It seems QCoreApplication event loop is not necessary for timer and socket events to be dispatched. So some QtCore modules require and instance of QCoreApplication, but there is no need to have a running application event loop.

Answer 1

You are conflating the existence of a QCoreApplication with a running event loop. Those two are separate concepts. You may well need the former for the latter, but the latter doesn’t have to run in the same thread as the former.

Most notably, you don’t really have to call qApp->exec() if you don’t have any events to dispatch in the thread where you constructed QCoreApplication.

The existence of a QCoreApplication is, as it were, a non-issue. Things get hairier with QApplication — you can start it in a non-gui thread, but it’s not portable and won’t work on OS X. I’m trying to figure out why it doesn’t work, but I don’t have much time now to offer a satisfactory solution — not yet.

It is also a misconception that QCoreApplication’s event loop needs to be running for socket notifications and timer events to be dispatched to other threads. A QCoreApplication’s event loop is nothing special. There is a platform-specific instance of QAbstractEventDispatcher that gets created for a thread when you instantiate the first QEventLoop in that thread. The QEventLoop doesn’t know anything specific about the platform.

QCoreApplication’s exec() method is quite simple and creates an instance of QEventLoop, and thus will create an instance of platform-specific QAbstractEventDispatcher. This instance is not special in any way. It’s the same as any other event dispatcher created in any other thread, as far as my code reading tells so far.

If all underlying window systems would support it, it’d be in fact possible to make Qt GUI code multithreaded — the per-thread event reception and dispatch is already there as a small first step. The big obstacle, probably the only one, would be the X library and its display lock. The display lock would be an obvious matter of contention between threads. You’d need each thread that wants to talk to the GUI open up a separate connection to the X server, and I don’t know if there’s a supported way of doing that from Xlib.