René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"PyThreadState Sometimes Used for Different Threads for Subinterpreters ","articleBody":"# Bug report\n\nIn a few places, we treat `PyInterpreterState.threads.head` (AKA `PyInterpreterState_ThreadHead()`) for subinterpreters as an unused thread state that we can use in a one-off manner:\n\n* `_PyInterpreterState_IDDecref()` (Python/pystate.c)\n* `_call_in_interpreter()` (Python/pystate.c) - fixed in 3.13+ (gh-109556)\n* `_run_script_in_interpreter()` (Modules/_xxsubinterpreter.c)\n* `interp_destroy()` (Modules/_xxsubinterpreter.c)\n\nThe problem is that each thread state should correspond to a single OS thread, and for each OS thread there should be at most one thread state per interpreter.  Using `PyInterpreterState.threads.head` like that violates those assumptions, which can cause problems. [^1]\n\n[^1]: Currently, this mostly doesn't affect the main interpreter.  Ideally, the main interpreter wouldn't actually be treated specially.  See gh-109857.\n\nAlso, some code assumes `PyInterpreterState.threads.head` is the current thread state, when it might not be:\n\n* `interpreter_clear()` (Python/pystate.c)\n* ...\n\nWe should fix this by always using the thread state that corresponds to the current thread (and create one if missing).  For efficiency, we can use a thread-local (via `PyThread_tss_*`) to store each interpreter's thread state for that thread.\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-110245\n* gh-110709\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/ericsnowcurrently","@type":"Person","name":"ericsnowcurrently"},"datePublished":"2023-09-25T17:08:27.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/109860/cpython/issues/109860"}