[issue3329] API for setting the memory allocator used by Python
Jukka Laurila jukka.p.laur...@nokia.com added the comment:
Brett is right. Macroing the memory allocator is a better choice than
forcing indirection on all platforms. We did this on Python for S60,
using the macros PyCore_{MALLOC,REALLOC,FREE}_FUNC for interpreter's
allocations, and then redirected those to a mechanism that allows to set
the allocator at runtime.
Sorry we don't have a clean patch at present for this change only, but
in case anyone's interested the full source is at
https://garage.maemo.org/frs/?group_id=854
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3329
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3329] API for setting the memory allocator used by Python
Jukka Laurila [EMAIL PROTECTED] added the comment: Brett, the ability to define the allocator dynamically at runtime could be a compile time option, turned on by default only on small memory platforms. On most platforms you can live with plain old malloc and may want to avoid the indirection. If no other platform is interested in this, we can just make it a Symbian-specific extension but I wanted to see if there's general interest in this. The application would control the lifecycle of the Python heap, and this seemed like the most natural way for the application to tell the interpreter which heap instance to use. Adam, the cleanup would work by freeing the entire heap used by Python after calling Py_Finalize. In the old PyS60 code we made Python 2.2.2 clean itself completely by freeing the Python-specific heap and making sure all pointers to heap-allocated items are properly reinitialized. Yes, there are various static pointers that are initially set to NULL, initialized to point at things on the heap and not reset to NULL at Py_Finalize, and these are currently an obstacle to calling Py_Initialize again. I'm considering submitting a separate ticket about that since it seems like the ability to free the heap combined with the ability to reinitialize the static pointers could together make full cleanup possible. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3329] API for setting the memory allocator used by Python
New submission from Jukka Laurila [EMAIL PROTECTED]: Currently Python always uses the C library malloc/realloc/free as the underlying mechanism for requesting memory from the OS, but especially on memory-limited platforms it is often desirable to be able to override the allocator and to redirect all Python's allocations to use a special heap. This will make it possible to free memory back to the operating system without restarting the process, and to reduce fragmentation by separating Python's allocations from the rest of the program. The proposal is to make it possible to set the allocator used by the Python interpreter by calling the following function before Py_Initialize(): void Py_SetAllocator(void* (*alloc)(size_t), void* (*realloc)(void*, size_t), void (*free)(void*)) Direct function calls to malloc/realloc/free in obmalloc.c must be replaced with calls through the function pointers set through this function. By default these would of course point to the C stdlib malloc/realloc/free. -- components: Interpreter Core messages: 69482 nosy: jlaurila severity: normal status: open title: API for setting the memory allocator used by Python type: feature request versions: Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1783] nonexistent data items declared as exports in sysmodule.h
New submission from Jukka Laurila: sysmodule.h contains the following declarations for data to be exported from the Python DLL, but these variables don't seem to exist anywhere: PyAPI_DATA(PyObject *) _PySys_TraceFunc, *_PySys_ProfileFunc; PyAPI_DATA(int) _PySys_CheckInterval; Either the declarations should be removed or the variables should be defined somewhere. I'm proposing the former. -- components: Interpreter Core messages: 59663 nosy: jlaurila severity: normal status: open title: nonexistent data items declared as exports in sysmodule.h versions: Python 2.5, Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1783 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
