On 09Jan2020 0429, Mark Shannon wrote:
There is a one-to-one correspondence between Python threads and O/S threads. So the threadstate can, and should, be stored in a thread local variable.
This is a major issue for embedders (and potentially asyncio), as it prevents integration with existing thread models or event loops.
Requiring an _active_ Python thread (~GIL held) to only run on a single OS thread is fine, but tying it permanently to a single OS thread makes things very painful. (Of course, this isn't the only thing that makes it painful, but if we're going to make this a deliberate design of CPython then we are essentially excluding entire interesting classes of embedding.)
Accessing thread local storage is fast. x86/64 uses the fs register to point to it, whereas ARM dedicates R15 (I think).
The register used is OS-specific. We do (and should) use the provided TLS APIs, but these add overhead.
Thread locals are not "global". Each sub-interpreter will have its own pool of threads. Each threadstate object should contain a pointer to its sub-interpreter.
I agree with this, but it's an argument for passing PyThreadState explicitly, which seems to go against your previous point (unless you're insisting that subinterpreters *must* be tied to specific and distinct "physical" threads, in which case let's argue about that because I think you're wrong :) ).
Cheers, Steve _______________________________________________ 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/QQRNUZMVGHGL5PLU6RCVKS74SKIYO22I/ Code of Conduct: http://python.org/psf/codeofconduct/
