Jeremy Maitin-Shepard added the comment:
Yes, I would agree that the new APIs are a useful addition regardless of the
PyThread_exit_thread change.
As far as the proposed `Py_SetThreadExitCallback` that seems like a fine thing
for applications to use, as long as it doesn't impac
Jeremy Maitin-Shepard added the comment:
To be clear, the problem I'm trying to address here is not specific to
embedding Python in a C++ application. In fact the issue came to my attention
while using Python directly, but loading an extension module that was written
in C++ usin
Jeremy Maitin-Shepard added the comment:
In general, I view hanging threads as the least bad thing to do when faced with
either acquiring the GIL or not returning at all. There is a lot of existing
usage of Python that currently poses a risk of random crashes and memory
corruption while
Jeremy Maitin-Shepard added the comment:
I suppose calling `Py_Initialize`, `Py_FinalizeEx`, then `Py_Initialize` again,
then `Py_FinalizeEx` again in an embedding application, was already not
particularly well supported, since it would leak memory.
However, with this change it also leaks
Change by Jeremy Maitin-Shepard :
--
keywords: +patch
pull_requests: +26916
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28525
___
Python tracker
<https://bugs.python.org/issu
Jeremy Maitin-Shepard added the comment:
It looks like the `_thread` module does not actually expose
`PyThread_exit_thread` --- the similarly named `thread_PyThread_exit_thread`
just raises SystemExit.
>From a search in the codebase, it appears `PyThread_exit_thread` is currently
&g
Jeremy Maitin-Shepard added the comment:
Regarding your suggestion of banning daemon threads: I happened to come across
this bug not because of daemon threads but because of threads started by C++
code directly that call into Python APIs. The solution I am planning to
implement is to add
Jeremy Maitin-Shepard added the comment:
Regarding your suggestion of adding a hook like `Py_SetThreadExitCallback`, it
seems like there are 4 plausible behaviors that such a callback may implement:
1. Abort the process immediately with an error.
2. Exit immediately with the original exit
Jeremy Maitin-Shepard added the comment:
Another possible resolution would to simply make threads that attempt to
acquire the GIL after Python starts to finalize hang (i.e. sleep until the
process exits). Since the GIL can never be acquired again, this is in some
sense the simplest way to
