gh-128555: Add 'context' keyword parameter to Thread.#128209
gh-128555: Add 'context' keyword parameter to Thread.#128209nascheme wants to merge 9 commits intopython:mainfrom
Conversation
nascheme
force-pushed
the
thread_inherit_context
branch
from
708127d to
808fa72
Compare
|
I wonder if |
Doc/library/threading.rst
Outdated
| Use the *target* name if *name* argument is omitted. | ||
|
|
||
| .. versionchanged:: 3.14 | ||
| Added the *context* parameter. Previously threads always ran with an empty |
There was a problem hiding this comment.
I think I'd make this more direct about the behavior change, perhaps something like:
"Threads now inherit the context of the caller of Thread.start instead of starting with an empty context. The context parameter was added. Pass a new contextvars.Context() if your thread requires an empty context."
This default change is a behavior change. Expect that to trip someones existing code up. I don't have the context (pun intended) as to how disruptive that could be. Per the PEP-387 breaking change policy we'd want to wait at least two releases. Which isn't so satisfying given the reasons you want this.
But a compromise could be considered (unsure if this is really wise) if needed: Change the default sooner than the deprecation when running in an experimental free-threading cpython build?
There was a problem hiding this comment.
I asked Sam what he thought about making this behavior enabled by default on free-threaded builds and he's okay with the idea. I've updated this PR to take that approach. I think we can wait a couple of releases to decide what to do about the default build. If it seems there is little breakage, we can change the default there too after a suitable period.
nascheme
changed the title
* Add ``sys.flags.inherit_context``. * Add ``-X inherit_context`` and :envvar:`PYTHON_INHERIT_CONTEXT`
nascheme
force-pushed
the
thread_inherit_context
branch
from
19d637a to
6d00c2a
Compare
nascheme
requested review from
a team,
1st1,
corona10,
ericsnowcurrently and
erlend-aasland
as code owners
|
Merged along with gh-130010. |
3 participants
Edit: this PR has been revised to make the behavior dependent on the build of Python used. The free-threaded build defaults to inheriting the context of the caller of
Thread.start(). The default behavior can be overridden by an-Xvar or by an environment variable. In the long term I think the behavior should be consistent between builds, both inheriting by default. The flag gives users of the default build an opt-in setting.Add the
sys.flags.thread_inherit_contextflag.This flag is set to true by default on the free-threaded build and false otherwise. If the flag is true, starting a new thread using
threading.Threadwill, by default, use a copy of thecontextvars.Contextfrom the caller ofthreading.Thread.startrather than using an empty context.Add the
-X thread_inherit_contextcommand-line option andPYTHON_THREAD_INHERIT_CONTEXTenvironment variable, which set thesys.flags.thread_inherit_contextflag.Add the
contextkeyword parameter tothreading.Thread. It can be used to explicitly pass a context value to be used by a new thread.Make the
_contextvarsmodule built-in.This was motivated by making the
warningsmodule work more reliably when threads and asyncio are used in combination withcatch_warnings. I'm working on a PR that will makewarningsuse a contextvar for the filtering state.Making new threads inherit context is not a new idea, it was suggested around the 3.10 release timeframe, gh-86981.
📚 Documentation preview 📚: https://cpython-previews--128209.org.readthedocs.build/