running pyqt app event loop in secondary thread, using (Py)Qt6.5

[Stefan Seefeld]

Hi Jeremy,
thanks for the quick reply !

On Fri, Sep 22, 2023 at 1:16 PM Jeremy Katz <jkatz at volexity.com> wrote:

>
> On 9/22/23 09:35, Stefan Seefeld wrote:
>
> > 1. run the above command, but click the "quit" button immediately. Thus
> > results in the error message `QObject::killTimer: Timers cannot be
> > stopped from another thread`,
> > followed by a segmentation fault
>
> My guess is that the QApplication object is being destroyed by the
> garbage collector, which isn't running in the QApplication's thread.
> Adding an explicit `del self.app` after the QApplication.exec returns
> prevents the crash for me.
>


Indeed, that works. (Unfortunately this approach is likely not to work in
general, as pytest appears to be holding on to references in different
places, making it highly unlikely that I can get the application's refcount
down to 0 at a specific time / location in the code.

Note that this is really just a test prototype I'm writing to understand
the underlying issues a little better. The real test logic will use a
QApplication that's exposed to Python using something other than sip
(boost.python), and I'm considering ways to deliberately circumventing the
reference counting, precisely so I can get back the control to delete the
underlying Qt objects whenever I need to, rather than when the Python
runtime would normally do it.



>
> This strategy likely won't work (AFAIK...) on macOS. While Qt is
> relatively happy to run in any thread, the mac UI interface must be used
> from the initial thread.
>
> > 2. rather than just "yielding" to the test function, yield the
> > application object (so the test function can interact with it). No
> > matter when you click the "quit" button, the result is the same as in 1.
> >
> > 3. call `h.app.quit()` after he `yield` (i.e. as soon as the test
> > function completes). Result: the application becomes unresponsive, but
> > doesn't stop
>
> 2 and possibly 3 sound like more instances of a wrong thread situation.
>

The call to `quit()` is documented to be thread-safe, so it should work
fine even when made programmatically from other threads than the one
running the event loop.
Is this potentially an issue with PyQt not routing the signal correctly ?

Thanks,

-- 

      ...ich hab' noch einen Koffer in Berlin...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20230922/a464d945/attachment-0001.htm>