Hi Jeremy,
thanks for the quick reply !

On Fri, Sep 22, 2023 at 1:16 PM Jeremy Katz <jk...@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 ?



      ...ich hab' noch einen Koffer in Berlin...
Interest mailing list

Reply via email to