pyqt5_enable_new_onexit_scheme vs. threads

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

pyqt5_enable_new_onexit_scheme vs. threads

Zach Pincus
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    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt
BPL
Reply | Threaded
Open this post in threaded view
|

Re: pyqt5_enable_new_onexit_scheme vs. threads

BPL
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 <[hidden email]> 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    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt

_______________________________________________
PyQt mailing list    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: pyqt5_enable_new_onexit_scheme vs. threads

Phil Thompson-5
In reply to this post by Zach Pincus
On 18/09/2019 18:12, Zach Pincus 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?

The latter option would be trivial to implement. Given that deleting a
running thread is guaranteed to cause a crash then it makes sense to
avoid that if possible - even if the root cause is an application design
bug.

Phil
_______________________________________________
PyQt mailing list    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: pyqt5_enable_new_onexit_scheme vs. threads

Zach Pincus
Thanks, Phil! That makes sense.

On Wed, Sep 18, 2019 at 4:07 PM Phil Thompson
<[hidden email]> wrote:

>
> On 18/09/2019 18:12, Zach Pincus 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?
>
> The latter option would be trivial to implement. Given that deleting a
> running thread is guaranteed to cause a crash then it makes sense to
> avoid that if possible - even if the root cause is an application design
> bug.
>
> Phil
_______________________________________________
PyQt mailing list    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Build PyQt5 from source with PyQt5-sip binary?

Zach Pincus
Hello,

I'm sorry if this is an obvious question, but I'm struggling a bit to
build PyQt5 from sources on my Mac. (So that I may test the fixed
onexit scheme from a nightly snapshot.)

In particular, I had assumed that the pip-installed PyQt5-sip package
would be sufficient to install to build PyQt5. However, this package
does not seem to provide a `sip` executable that can be used for this
purpose. The description of the PyQt5-sip package on PyPI seems to
suggest that the code generation tool is part of the install, but
perhaps it isn't?
https://pypi.org/project/PyQt5-sip/

Anyhow, is there a way to get PyQt5-sip to produce an executable (or
another straightforward way to get a sip binary / executable), or do I
pretty much need to install sip from source (or from a package
manager) in order to build PyQt5?

Thanks a ton, and sorry again if this is obvious,
Zach
_______________________________________________
PyQt mailing list    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: Build PyQt5 from source with PyQt5-sip binary?

Florian Bruhin
On Fri, Sep 20, 2019 at 01:49:56PM -0500, Zach Pincus wrote:
> I'm sorry if this is an obvious question, but I'm struggling a bit to
> build PyQt5 from sources on my Mac. (So that I may test the fixed
> onexit scheme from a nightly snapshot.)

pyqt5_enable_new_onexit_scheme() is part of the PyQt 5.13.1 release, so you
don't need to build anything from sources to test it.

> Anyhow, is there a way to get PyQt5-sip to produce an executable (or
> another straightforward way to get a sip binary / executable), or do I
> pretty much need to install sip from source (or from a package
> manager) in order to build PyQt5?

I always build it from source - it's quite painless and takes 5 seconds or so
to build.

Florian

--
https://www.qutebrowser.org | [hidden email] (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
         I love long mails! | https://email.is-not-s.ms/

_______________________________________________
PyQt mailing list    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Build PyQt5 from source with PyQt5-sip binary?

Phil Thompson-5
In reply to this post by Zach Pincus
On 20/09/2019 19:49, Zach Pincus wrote:

> Hello,
>
> I'm sorry if this is an obvious question, but I'm struggling a bit to
> build PyQt5 from sources on my Mac. (So that I may test the fixed
> onexit scheme from a nightly snapshot.)
>
> In particular, I had assumed that the pip-installed PyQt5-sip package
> would be sufficient to install to build PyQt5. However, this package
> does not seem to provide a `sip` executable that can be used for this
> purpose. The description of the PyQt5-sip package on PyPI seems to
> suggest that the code generation tool is part of the install, but
> perhaps it isn't?
> https://pypi.org/project/PyQt5-sip/

That is the PyQt5.sip module - nothing else.

> Anyhow, is there a way to get PyQt5-sip to produce an executable (or
> another straightforward way to get a sip binary / executable), or do I
> pretty much need to install sip from source (or from a package
> manager) in order to build PyQt5?

You need to build sip from the source package...

https://www.riverbankcomputing.com/static/Docs/PyQt5/installation.html#building-and-installing-from-source

Phil
_______________________________________________
PyQt mailing list    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt