GeezerVison is showing github.com — [subinterpreters] Add --experimental-isolated-subinterpreters build option · Issue #84694 · python/cpython
[subinterpreters] Add --experimental-isolated-subinterpreters build option #84694Description
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 = <Date 2020-10-31.22:59:17.920>
created_at = <Date 2020-05-05.13:13:51.880>
labels = ['expert-subinterpreters', 'build', '3.10']
title = '[subinterpreters] Add --experimental-isolated-subinterpreters build option'
updated_at = <Date 2020-10-31.22:59:17.920>
user = 'https://github.com/vstinner' bugs.python.org fields:
activity = <Date 2020-10-31.22:59:17.920>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2020-10-31.22:59:17.920>
closer = 'vstinner'
components = ['Build', 'Subinterpreters']
creation = <Date 2020-05-05.13:13:51.880>
creator = 'vstinner'
dependencies = []
files = []
hgrepos = []
issue_num = 40514
keywords = ['patch']
message_count = 6.0
messages = ['368141', '368156', '368159', '368172', '369401', '370745']
nosy_count = 3.0
nosy_names = ['vstinner', 'eric.snow', 'corona10']
pr_nums = ['19926', '20228']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue40514'
versions = ['Python 3.10'] Linked PRs
Activityvstinner commented on May 5, 2020 Modifying Python internals to have one GIL per interpreter (bpo-40512) is a large project which requires to modify many small things (again, see bpo-40512).
I propose to add a temporary build --experimental-isolated-subinterpreters build option to configure for developers who want to hack on isolated subinterpreters. The intent is to speedup bpo-40512 development by making some practice compromises, to have more time to properly design the real fixes.
For example, tuple, dict and frame have free lists which are shared by subinterpreters. A practical solution is to simply disable them at build time to avoid the need to have per-interpreter free lists.
Another example is pymalloc which is shared by all subinterpreters and rely on the unique global interpreter lock (GIL) to protect its internal states. A practical solution is to disable it and force the usage of libc malloc() function instead.
Some compromosises cannot be the default since they have a significant negative impact on performances. So I propose to add a temporary build option until all these small issues will be fixed. vstinner commented on May 5, 2020 vstinner commented on May 5, 2020 --with-experimental-isolated-subinterpreters option name is very long on purpose: to advertize that you must not use it, unless you fully understand its purpose :-)
I didn't document the build option in Misc/SpecialBuilds.txt or Doc/whatsnew/3.9.rst on purpose: you should not use this special build :-) Basically, this option is only for Eric Snow and me :-D ericsnowcurrently commented on May 5, 2020 It would probably make sense to remove the build option in the 3.9 release. We can leave it in master, but remove it in the 3.9 branch once it has been created. changed the title [-]Add --experimental-isolated-subinterpreters build option[/-] [+][subinterpreters] Add --experimental-isolated-subinterpreters build option[/+] on May 15, 2020changed the title [-]Add --experimental-isolated-subinterpreters build option[/-] [+][subinterpreters] Add --experimental-isolated-subinterpreters build option[/+] on May 15, 2020vstinner commented on May 19, 2020 vstinner commented on Jun 5, 2020 I started to *remove* a few"#ifdef EXPERIMENTAL_ISOLATED_SUBINTERPRETERS":
- commit 88ec919: Make list free list per-interpreter
- commit 3744ed2: Make frame free list per-interpreter
- PR 20645 (under review): Make dict free lists per-interpreter
kumaraditya303 commented on May 25, 2022 erlend-aasland commented on May 25, 2022
Reopened for #93185
Why do you need to reopen it? The title says "add --experimental-isolated-subinterpreters build option". If you are to remove it, it can be done in the new issue, no? kumaraditya303 commented on May 25, 2022 I reopened it as #93185 uses this issue in title, if that PR will use a new issue, this can be closed. erlend-aasland commented on May 25, 2022 Use #93185 for the removal; there is no need for this to be reopened.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|