Repository navigation
new thread doesn't copy context of the parent thread #86981
Description
| BPO | 42815 |
|---|---|
| Nosy | @gvanrossum, @jcea, @1st1, @uriyyo, @adriangb |
| PRs |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2021-01-03.11:43:34.701>
labels = ['type-bug', 'library', '3.10']
title = "new thread doesn't copy context of the parent thread"
updated_at = <Date 2021-08-04.18:05:52.773>
user = 'https://github.com/uriyyo'bugs.python.org fields:
activity = <Date 2021-08-04.18:05:52.773>
actor = 'adriangb'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2021-01-03.11:43:34.701>
creator = 'uriyyo'
dependencies = []
files = []
hgrepos = []
issue_num = 42815
keywords = ['patch']
message_count = 2.0
messages = ['384262', '398642']
nosy_count = 5.0
nosy_names = ['gvanrossum', 'jcea', 'yselivanov', 'uriyyo', 'adriangb']
pr_nums = ['24074']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue42815'
versions = ['Python 3.10']
Activity
uriyyo commentedon Jan 3, 2021
New thread doesn't copy context of the parent thread.
The minimal example to reproduce the issue:
Is it expected behavior?
PEP-567 I didn't find anything regarding this case.
gvanrossum commentedon Jul 31, 2021
Trust me, it's too late to fix this in 3.10.
ryangalamb commentedon Dec 4, 2022
As I read PEP-567, it looks like contextvars were not intended to be automatically copied into new threads. One of the examples describes how to use a copy of the current thread's context vars in another thread: https://peps.python.org/pep-0567/#offloading-execution-to-other-threads
Furthermore,
threading.local()doesn't automatically copy its values into new threads, and (as I understand)contextvarsis intended to be consistent withthreading.local().It is a bit surprising that scheduling an
asynciotask will copy the current context, while new threads get an empty context. But I expect the intention there was to be consistent withthreading.local(). (When you schedule an asyncio task, it's still going to be in the same thread and have access to the same thread-local variables.)tl;dr I think this is working as intended, and we can close this issue. (But I agree that the behavior is bit surprising.)
gvanrossum commentedon Dec 6, 2022
Thanks for doing this research; I agree that we can close this.
I don't want to speculate on the reasons for starting a new thread with an empty context; maybe it was an oversight, maybe it was being strict in the layering of dependencies (contexts depend on threads, so threads shouldn't depend on contexts), maybe it was something else. Maybe Yury could tell us, but he's got bigger things on his mind.