Repository navigation
Remove PyEval_ReInitThreads() from the public C API #80909
Description
Activity
PyEval_ReInitThreads() is used internally by PyOS_AfterFork_Child(). I don't see the point of calling it directly. If you care of threads after fork, just call PyOS_AfterFork_Child(), no?
I propose to remove PyEval_ReInitThreads() from the public C API.
Problem: it's documented as a public function in High-level API of the Python Initialization API:
https://docs.python.org/dev/c-api/init.html#c.PyEval_ReInitThreadsOn the Internet, I found a single project calling directly this function, but it's only in a test used to the test Python threading API:
https://github.com/DataDog/go-python3/blob/master/thread_test.gofunc TestThreadInitialization(t *testing.T) {
Py_Initialize()
PyEval_InitThreads()assert.True(t, PyEval_ThreadsInitialized()) PyEval_ReInitThreads() }
I don't think that the PyEval_ReInitThreads() call here makes any sense.
- added3.8 (EOL)end of lifeend of lifeinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)
on Apr 25, 2019 The function was added 19 years ago:
commit fee3a2d
Author: Guido van Rossum <guido@python.org>
Date: Sun Aug 27 17:34:07 2000 +0000Charles Waldman's patch to reinitialize the interpreter lock after a fork. This solves the test_fork1 problem. (ceval.c, signalmodule.c, intrcheck.c) SourceForge: [ Patch bpo-101226 ] make threading fork-safefwiw - i agree that this can be removed. it has no reason to ever be called directly. i double checked in our massive internal codebase at work and found no calls other than python interpreters themselves.
i double checked in our massive internal codebase at work and found no calls other than python interpreters themselves.
Thanks. It confirms what I understood using GitHub code search (see my initial message).
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: