Message 202164 - Python tracker

➜

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	Arfrever, pitrou, serhiy.storchaka, vstinner
Date	2013-11-04.20:22:11
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<CAMpsgwYoKtSPiPw_COmHEkcFROv85+Sy6rGhLLtPDJMO8aRiQA@mail.gmail.com>
In-reply-to	<1383592337.06.0.220241455615.issue19466@psf.upfronthosting.co.za>

Content
2013/11/4 Antoine Pitrou <report@bugs.python.org>: > I'm afraid clearing thread states is a bit too brutal. What if some destructor relies on contents of the thread states (e.g. thread locals)? When Py_Finalize() is called, only one Python thread hold the GIL. After _Py_Finalizing=tstate is set, no other thread can hold the GIL. If another Python tries to lock the GIL, it is "killed" by PyEval_RestoreThread(). Is that correct? If yes, in which thread would the destructor be called? Would it read Python thread locals without holding the GIL?

2013/11/4 Antoine Pitrou <report@bugs.python.org>:
> I'm afraid clearing thread states is a bit too brutal. What if some destructor relies on contents of the thread states (e.g. thread locals)?

When Py_Finalize() is called, only one Python thread hold the GIL.
After _Py_Finalizing=tstate is set, no other thread can hold the GIL.
If another Python tries to lock the GIL, it is "killed" by
PyEval_RestoreThread().

Is that correct? If yes, in which thread would the destructor be
called? Would it read Python thread locals without holding the GIL?

History
Date	User	Action	Args
2013-11-04 20:22:12	vstinner	set	recipients: + vstinner, pitrou, Arfrever, serhiy.storchaka
2013-11-04 20:22:12	vstinner	link	issue19466 messages
2013-11-04 20:22:11	vstinner	create