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
