Re: pyqt5_enable_new_onexit_scheme vs. threads
BPL <[email protected]>
| Newsgroups | gmane.comp.python.pyqt-pykde |
|---|---|
| Message-ID | <CAAfY3fYHAWy3++EG6J-kbWXfcErWf4K+VVL0W3Tx9y5b1s-iBg@mail.gmail.com> |
Zach, First of all, thanks to test out as suggested. That said, I'm sure it'd be helpful for pyqt devs if you provided a http://sscce.org/ as well as the environment you used to test. Thanks in advance. On Wed, Sep 18, 2019 at 7:13 PM Zach Pincus <[email protected]> wrote: > Hello, > > As requested, I tested out pyqt5_enable_new_onexit_scheme(True) with > my application on PyQt 5.13.1. > > At exit, I get the following error: > QThread: Destroyed while thread is still running > and a segfault. > > The application spins up a background QThread that currently has no > provision for exiting on termination. (It exists to upload textures to > an offscreen OpenGL context, and otherwise is just blocked waiting for > a new texture to upload.) Without the new onexit scheme, this works > just fine. > > I'm sure this reveals a design flaw in the original application (the > thread should probably try to exit cleanly, rather than just die > during application exit), but this is at least one case where the new > onexit scheme will cause errors to crop up that did not exist before. > > What would be the best way to make the thread exit cleanly? At atexit > python callback that sets a flag to make the thread exit and then > waits on the thread? Or connecting (something?) to the aboutToQuit > signal that does the same? Or should the new onexit scheme not touch > threads in the first place? > > Thanks, > Zach > _______________________________________________ > PyQt mailing list [email protected] > https://www.riverbankcomputing.com/mailman/listinfo/pyqt > _______________________________________________ PyQt mailing list [email protected] https://www.riverbankcomputing.com/mailman/listinfo/pyqt