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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest