Message 402487 - Python tracker

Message402487

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 :-(

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:23	vstinner	set	recipients: + vstinner, gregory.p.smith, izbyshev, jbms
2021-09-23 10:07:23	vstinner	set	messageid: <1632391643.77.0.739328800832.issue42969@roundup.psfhosted.org>
2021-09-23 10:07:23	vstinner	link	issue42969 messages
2021-09-23 10:07:23	vstinner	create