gh-135944: Add a "Runtime Components" Section to the Execution Model Docs #135945
Conversation
ericsnowcurrently
added
skip news
needs backport to 3.13
| @@ -398,6 +398,75 @@ See also the description of the :keyword:`try` statement in section :ref:`try` | |||
| and :keyword:`raise` statement in section :ref:`raise`. | |||
|
|
|||
|
|
|||
| .. _execcomponents: | |||
|
|
|||
| Runtime Components | |||
There was a problem hiding this comment.
I think it would be a good idea to mention that this is CPython specific. Other implementations are allowed to have different runtime models.
There was a problem hiding this comment.
This is meant to be implementation agnostic
Oh, oops, didn't see this. Some parts are CPython specific here, though.
There was a problem hiding this comment.
I'm trying to avoid any CPython-specific notions here. Do you have an example of another runtime model?
There was a problem hiding this comment.
No, I'm not familiar with how any other implementations work, this is coming solely off a bit of speculation on my part. My concern is that a thread is inherently CPython-specific, because some Python implementations exist in areas that don't have access to OS threads, such as Brython for JS, and probably MicroPython/CircuitPython for some microcontrollers.
I do think that this is a great section to have for subinterpreters, I just think it'd be better to keep some parts of it CPython specific. Does that make sense?
There was a problem hiding this comment.
From a conceptual standpoint, which is the level of this text, threads are not implementation-specific (or platform-specific): the Python runtime always deals with at least the one thread in which it was started. Not all platforms and implementations support multiple threads, but that's a different matter. I'll add a sentence clarifying that point.
There was a problem hiding this comment.
Ok, I think I can get behind that. Thanks!
| interpreter | ||
| Python thread (runs bytecode) | ||
|
|
||
| when a Python program starts, it looks exactly like that, with one |
| If the runtime supports using multiple interpreters then each OS thread | ||
| will have at most one Python thread for each interpreter. However, | ||
| only one is active in the OS thread at a time. Switching between | ||
| interpreters means changing the active Python thread. |
There was a problem hiding this comment.
Probably I'm misreading:
| If the runtime supports using multiple interpreters then each OS thread | |
| will have at most one Python thread for each interpreter. However, | |
| only one is active in the OS thread at a time. Switching between | |
| interpreters means changing the active Python thread. | |
| If the runtime supports using multiple interpreters then each OS thread | |
| will have at least one Python thread for each interpreter. However, | |
| only one is active in the OS thread at a time. Switching between | |
| interpreters in the current OS thread means changing the active Python thread. |
There was a problem hiding this comment.
It's "at most" because there may be zero or one Python thread per thread per interpreter. However, that isn't strictly true, since you can create as many thread states as you want. Only one can be active at a time for a give thread and each one is strictly bound to a single thread. I'll tweak the wording. Thanks for pointing this out.
The section provides a brief overview of the Python runtime's execution environment.
This is meant to be implementation agnostic, If that doesn't hold true then we should take a different approach.
📚 Documentation preview 📚: https://cpython-previews--135945.org.readthedocs.build/