Moving threadstate to thread-local storage.
Hi, As an experiment, I thought I would try moving the thread state (what you get from _PyThreadState_GET() ) to TLS. https://github.com/python/cpython/compare/master...markshannon:threadstate_i... It works, passing all the tests, and seems sound. It is a small patch (< 50 lines) and doesn't increase the overall code size. My branch is GCC/Clang only, so will need a bit of extra code for Windows. It should only need a few more lines; I haven't done it as I don't have a Windows machine to test it on. This is a *much* cleaner approach to removing the global variable than adding lots of extra parameters all over the place. Cheers, Mark.
Does it work with subinterepreters? Especially when a native thread has two Python thread states of two different interpreters. Victor Le mar. 24 mars 2020 à 16:36, Mark Shannon <mark@hotpy.org> a écrit :
Hi,
As an experiment, I thought I would try moving the thread state (what you get from _PyThreadState_GET() ) to TLS.
https://github.com/python/cpython/compare/master...markshannon:threadstate_i...
It works, passing all the tests, and seems sound.
It is a small patch (< 50 lines) and doesn't increase the overall code size.
My branch is GCC/Clang only, so will need a bit of extra code for Windows. It should only need a few more lines; I haven't done it as I don't have a Windows machine to test it on.
This is a *much* cleaner approach to removing the global variable than adding lots of extra parameters all over the place.
Cheers, Mark. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RPSTDB6A... Code of Conduct: http://python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.
On 24/03/2020 5:26 pm, Victor Stinner wrote:
Does it work with subinterepreters? Especially when a native thread has two Python thread states of two different interpreters.
A native thread can only have one Python thread at a time, and must switch using the PyThreadState_Swap() API. So, I think the answer is yes. Do you have a specific example or testcase?
Victor
Le mar. 24 mars 2020 à 16:36, Mark Shannon <mark@hotpy.org> a écrit :
Hi,
As an experiment, I thought I would try moving the thread state (what you get from _PyThreadState_GET() ) to TLS.
https://github.com/python/cpython/compare/master...markshannon:threadstate_i...
It works, passing all the tests, and seems sound.
It is a small patch (< 50 lines) and doesn't increase the overall code size.
My branch is GCC/Clang only, so will need a bit of extra code for Windows. It should only need a few more lines; I haven't done it as I don't have a Windows machine to test it on.
This is a *much* cleaner approach to removing the global variable than adding lots of extra parameters all over the place.
Cheers, Mark. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RPSTDB6A... Code of Conduct: http://python.org/psf/codeofconduct/
Hi Mark, Le mar. 24 mars 2020 à 21:05, Mark Shannon <mark@hotpy.org> a écrit :
A native thread can only have one Python thread at a time, and must switch using the PyThreadState_Swap() API.
Right.
So, I think the answer is yes.
Nice.
Do you have a specific example or testcase?
I don't know well the C API of subinterpreters. Usually, I look at _testcapi.run_in_subinterp(). This function is used by multiple unit tests checking the behavior of subinterpreters. -- My expectation is that the different ways to get the current Python thread state works as expected. PyThreadState *tstate = PyThreadState_Get(); /* PyThreadState_GET() is an alias to PyThreadState_Get() */ PyThreadState *tstate = _PyThreadState_GET(); I also expect that tstate->interp is the current interpreter. What is the behavior when the GIL is released? Is tstate equal to NULL when the GIL is released? -- The less clear part is the PyGILState API: PyThreadState *tstate = PyGILState_GetThisThreadState(); Does it return the current Pyhon thread state and is tstate->interp the current interpreter? Victor -- Night gathers, and now my watch begins. It shall not end until my death.
On 2020-03-24 16:31, Mark Shannon wrote:
Hi,
As an experiment, I thought I would try moving the thread state (what you get from _PyThreadState_GET() ) to TLS.
https://github.com/python/cpython/compare/master...markshannon:threadstate_i...
It works, passing all the tests, and seems sound.
It is a small patch (< 50 lines) and doesn't increase the overall code size.
My branch is GCC/Clang only, so will need a bit of extra code for Windows. It should only need a few more lines; I haven't done it as I don't have a Windows machine to test it on.
What about other compilers? AFAIK, __thread is a a non-standard name for a C11+ feature. Is there a good way to do this in C99?
participants (3)
-
Mark Shannon -
Petr Viktorin -
Victor Stinner