The first part of the condition here is checking if any of the bits of_PY_LOCK_PYTHONLOCK are set. In other words, it will pass even if only_PY_LOCK_DETACH is set fromPyMutex_Lock().

It could be:

if ((flags & _PY_LOCK_PYTHONLOCK) == _PY_LOCK_PYTHONLOCK && Py_IsFinalizing()) {

But given that this is an easy mistake to make and hard to spot, I'd rather just have a separate bit for fail-on-finalization and check that individual bit here.

If we want a constant to combine those three bits, let's keep that constant it in_threadmodule.c.

🤦

Won't this be prone to TOCTOU issues?Py_IsFinalizing could pass, but once the thread state detaches in the parking lot, the interpreter is free to start finalizing. The parking lot will then hang the thread upon reattachment in_PySemaphore_Wait, right?

No - this check is only relevant for the main thread (the one that performsPy_Finalize()) so there's no TOCTOU. There are two "hanging" threads behaviors that you may be confusing:

1. Non-main threads, typically daemon threads (and occasionally other non-daemon threads), hang when they try to attach during Python finalization. This PR doesn't affect that behavior.
2. The main thread, when performing finalization, may acquirethreading.Lock/RLock called via destructors / GC. If those locks happen to be held by other (now hung) threads, then the shutdown would deadlock. This instead raises a Python exception.

Hm, yeah, I was confusing it with that. But, you've mentioned before that acquiring Python locks in finalizers isn't safe regardless of finalization, because the GC might run in any code where the lock is held and deadlock while reacquiring it. Looking at the test case, I think that still applies. What's the use-case that this PR is fixing?