On Thu, 9 Jan 2020 15:12:41 +0100
Victor Stinner <vstin...@python.org> wrote:
>
> Getting the interpreter from a Python thread state is trivial: interp
> = tstate->interp.
>
> The problem is how to get the current Python thread state.
> *Currently*, it's an atomic variable. But tomorrow with multiple
> interpreters running in parallel, I expect that it's going to me more
> expensive like first having the current the interpreter running the
> current native thread, and then get the Python thread state of this
> interpreter. Or something like that. We may get more and more
> indirections...
It can still be simple. Store the current interpreter in a
thread-local variable (there can be only one interpreter running at a
given time in a given OS thread, even if it's not always the same
interpreter). Then have the interpreter struct contain a pointer to the
current running thread *in that interpreter*.
So you have one thread-local access to the current interpreter and then
a normal struct member access to the current thread state.
For example:
struct _ts;
struct _is {
struct _ts* current_thread;
};
_Thread_local struct _is *current_interp;
inline struct _is *_PyInterpreterState_GET() {
return current_interp;
}
inline struct _ts *_PyThreadState_GET() {
return current_interp->current_thread;
}
Regards
Antoine.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/GNJTJQ3WPZLB3VY2EJ62443GTL3L2CFI/
Code of Conduct: http://python.org/psf/codeofconduct/
