➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients gregory.p.smith, izbyshev, jbms, vstinner
Date 2021-09-23.10:07:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1632391643.77.0.739328800832.issue42969@roundup.psfhosted.org>
In-reply-to
Content 
I'm not comfortable with PR 28525 which always hang threads which attempt to acquire the GIL after Python exited.

I would prefer to keep the current behavior by default, but give the ability to applications embedding Python to decide what to do.

With my Py_SetThreadExitCallback(func) idea, PyThread_exit_thread() would call func() and then pthread_exit(0). Applications can hang threads, log a message, call abort(), or whatever else.

I'm not comfortable with writing a portable function to "hang a thread". For example, I don't understand why PR 28525 processes Windows messages on hang threads.

Well, it's a complex problem :-(
History
Date User Action Args
2021-09-23 10:07:23vstinnersetrecipients: + vstinner, gregory.p.smith, izbyshev, jbms
2021-09-23 10:07:23vstinnersetmessageid: <1632391643.77.0.739328800832.issue42969@roundup.psfhosted.org>
2021-09-23 10:07:23vstinnerlinkissue42969 messages
2021-09-23 10:07:23vstinnercreate