[Interest] running Qt main event loop in secondary thread

[Thiago Macieira]

On Monday, 27 March 2023 13:23:02 PDT Stefan Seefeld wrote:
> Hello,
> 
> 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 
there.

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...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20230327/3eb200b9/attachment.bin>