Repeated Python Thread State creation and destruction for foreign threads is slow

Feature or enhancement

Proposal:

Terminology: foreign thread - An OS thread not created by CPython itself, such as by Rust or C code.

1.) "don't do that" - sure - that's the documentation PR I'll put up to start with, code can manually work around this and improve its performance today. this works on existing Python versions. it matters more on free-threading builds due to their additional allocation overheads but is a meaningful improvement on old-style traditional builds as well.

2.) Simple C API patterns for calling into the CPython interpreter lead to tripping over this performance problem. A classic PyGILState_Ensure() + PyGILState_Release() combo surrounding the call into CPython in a foreign worker thread creates a new Python Thread State via Ensure and destroys it again upon Release. So if you're a foreign thread repeatedly calling into the interpreter (such as a thread pool)... it hurts.

I'm filing this rather than only doing a documentation addition as I think we might be able to make this work smoother by default in many cases without the complications code needs to deal with to prevent it.

One (not well fleshed out) idea to explore - what if we kept a cache of recent ready but no longer referenced thread states for trivial resurrection instead of destroying them upon Release?

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

Linked PRs

• gh-146221
• gh-152644

首先查看 gh-146221 和 gh-152644 中链接的工作，然后跟踪本 issue 中描述的 PyGILState_Ensure() 和 PyGILState_Release() 行为。完成这项工作需要就减少外部线程状态的重复创建和销毁达成一致方案，并验证其性能和正确性。