[Interest] running Qt main event loop in secondary thread
thiago.macieira at intel.com
Tue Mar 28 06:52:37 CEST 2023
On Monday, 27 March 2023 13:23:02 PDT Stefan Seefeld wrote:
> I'm working on some Python tests that interact with a Qt application. I
> would like to run the application's event loop in a secondary thread, so
> the primary thread can perform the test itself.
> I read in the past that such a use-case wasn't supported by Qt, but I can't
> find that information right now, and neither do I remember the rationale
> for that limitation.
>From Qt's point of view, as well as from the C and C++ one, one thread isn't
different from any other. Any thread can assume any responsibility.
What Qt cares about, specifically the QCoreApplication event loop (which is the
GUI event loop if you have a GUI) is the *first* thread in which *any* QObject
is created. We also ask that that first QObject be QCoreApplication itself, but
it isn't required to be so. In theory it would be possible to let
QCoreApplication be created in any thread, but it's not implemented and also
not something we'll spend time on.
> For context: my application is somewhat atypical in that the application
> only has a minimal GUI, but does a lot of processing of input from TCP/IP.
So GUI in the main thread and processing of data auxiliary thread(s). The
networking itself may be the main thread, those auxiliary threads, or
dedicated network threads. This is the typical design of such applications.
> The test logic I'd like to write would thus have test function (running in
> the primary thread) control the data sent to the app and inspect and assert
> the application's corresponding states, while the event processing would
> take place in a secondary thread.
If your GUI is minimal, then it doesn't matter where it runs; that means it
can run in the main thread while you create the data that will be processed by
your networking code. Or you can create the data in yet more auxiliary threads
too. There's nothing in your design that requires your data-creation to be the
main thread nor the shunting of the GUI into an auxiliary one.
Also... you don't need a GUI for testing. You should make it so no windows are
shown and therefore no GUI input is processed while in test mode. That means
you don't have to exec() the Qt GUI event loop.
> I'm unfortunately not sure that such a use-case is possible at all, i.e. I
> may have to invert roles, i.e. have the actual "test scenario" be executed
> in a secondary thread as the main thread is reserved for the (blocking)
> event loop.
You can do what you want too. Like I said, just make sure no QObject is
created before you start this other thread and create the QCoreApplication in
Do note that some libraries may create QObjects by simply linking to them.
QtCore doesn't do that. I make no statements about any other Qt library,
including QtGui itself. If that happens, you may need to move the Qt code to a
plugin so you can delay loading it until the auxiliary thread is created.
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5152 bytes
Desc: not available
More information about the Interest