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 ? Thanks, -- ...ich hab' noch einen Koffer in Berlin...
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest