[Python-Dev] Python initialization and embedded Python (original) (raw)
Eric Snow ericsnowcurrently at gmail.com
Tue Nov 21 10:57:14 EST 2017
- Previous message (by thread): [Python-Dev] Python initialization and embedded Python
- Next message (by thread): [Python-Dev] Python initialization and embedded Python
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Nov 20, 2017 at 3:03 PM, Victor Stinner <victor.stinner at gmail.com> wrote:
To statically initialize PyMemAllocatorEx fields, you need to export a lot of allocator functions. I would prefer to not do that.
[snip] The rules to choose the allocator to each domain are also complex depending if pymalloc is enabled, debug hooks are enabled by default, etc. The memory allocator is also linked to PyMemDebug which is not currently in Include/internals/ but Objects/obmalloc.c.
I'm not suggesting supporting the full machinery. Rather, as my PR demonstrates, we can statically initialize the minimum needed to support pre-init use of PyMem_RawMalloc() and PyMem_RawFree(). The allocators will be fully initialized once the runtime is initialized (i.e. once Py_Initialize() is called), just as they are now.
FWIW, I'm not sure that's the best approach. See my notes in https://bugs.python.org/issue32096.
I understand that moving global variables to PyRuntime helps to clarify how these variables are initialized and then finalized, but memory allocators are a complex corner case.
Agreed. I spent a large portion of my time getting the allocators right when working on the original _PyRuntime patch. It's tricky code.
-eric
- Previous message (by thread): [Python-Dev] Python initialization and embedded Python
- Next message (by thread): [Python-Dev] Python initialization and embedded Python
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]