Author jlaurila
Recipients Rhamphoryncus, brett.cannon, jlaurila
Date 2008-07-10.08:05:12
SpamBayes Score 8.77733e-05
Marked as misclassified No
Message-id <1215677136.98.0.287675991536.issue3329@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2008-07-10 08:05:37jlaurilasetspambayes_score: 8.77733e-05 -> 8.77733e-05
recipients: + jlaurila, brett.cannon, Rhamphoryncus
2008-07-10 08:05:37jlaurilasetspambayes_score: 8.77733e-05 -> 8.77733e-05
messageid: <1215677136.98.0.287675991536.issue3329@psf.upfronthosting.co.za>
2008-07-10 08:05:35jlaurilalinkissue3329 messages
2008-07-10 08:05:31jlaurilacreate