-
-
Notifications
You must be signed in to change notification settings - Fork 31k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature: support pymalloc for subinterpreters. each subinterpreter has pymalloc_state #87479
Comments
ericsnowcurrently/multi-core-python#73 JunyiXie@8209548 |
Made two changes:
I extend _xxsubinterpretermodule.c to support call any function in sub interpreter.
so i think, in _sharednsitem_init _copy_raw_string, need malloc by PyMem_RawAPI. easy to management.
|
github pr |
There is a problem: it's cause a problem.
I think it has two way to slove this problem:
|
malloc pointer in interpreterA and free pointer in interpreterB is usual. |
by the way, |
when finalize_interp_delete, we need keep interpreter pymalloc pool in linked list.It will be used when search memory in pymalloc pools. |
I'm not sure that it's needed to have a "per interpreter" allocator. The needed feature is to be able to call PyMem_Malloc() in parallel in different threads. If I understood correctly, the glibc malloc has a per-thread fast allocator (no locking) and then falls back to a slow allocator (locking) if the fast allocator failed. Maybe pymalloc could have per-thread memory arenas. When I implemented the PEP-587, I spend a significant amount of time to avoid using pymalloc before Py_Initialize() is called: only use PyMem_RawMalloc() before Py_Initialize(). But I'm not 100% sure that pymalloc is not used before Py_Initialize() nor *after* Py_Finalize(). For example, we should check if a daemon thread can call PyMem_Malloc() after Py_Finalize(), even if they are supposed to exit as soon as they try to acquire the GIL, even the GIL must be held to use pymalloc (to use PyMem_Malloc and PyObject_Malloc): See also bpo-37448: |
The current workaround is to disable pymalloc when Python is built with EXPERIMENTAL_ISOLATED_SUBINTERPRETERS: _PyPreConfig_InitCompatConfig(PyPreConfig *config): #ifdef EXPERIMENTAL_ISOLATED_SUBINTERPRETERS
/* bpo-40512: pymalloc is not compatible with subinterpreters,
force usage of libc malloc() which is thread-safe. */
#ifdef Py_DEBUG
config->allocator = PYMEM_ALLOCATOR_MALLOC_DEBUG;
#else
config->allocator = PYMEM_ALLOCATOR_MALLOC;
#endif
#else
...
#endif |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: