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/

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

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