[Patches] Re: Garbage collection patches for Python

[Moshe Zadka]

On Wed, 9 Feb 2000 nascheme@enme.ucalgary.ca wrote:

<about pcre>
> > This one is "buggy" for sure. The PCRE code allocates memory through
> > the proprietary functions "pcre_malloc/pcre_free" (which default to
> > malloc/free), so I really don't see why there's code inside mentioning
> > "free" and not "pcre_free".
> 
> No, I think it is okay.  All the memory allocated with
> pcre_malloc is deallocated with pcre_free.  The places that use
> free haved been changed to PyMem_FREE because that memory has
> come from the Python interpeter.  I spent some time tracking this
> one down.

Well, actually pcre should be a no brainer: it was written with "weird"
allocators in mind: IMHO, Python should just set pcre_malloc/pcre_free 
to PyMem_Malloc and PyMem_FREE. Things should be easier then.

> Its very ugly.  Readline returns memory allocated by malloc.
> That memory is eventually freed from within the interpreter by
> PyMem_FREE.  We can't change the PyMem_FREE call to free because
> it also frees memory allocated by PyMem_MALLOC.

Ummm....isn't there some way to override readline's allocator? 
if not, then it might not be a bad idea to submit a patch to the 
readline maintainer allowing that. Guile has GC and IIRC uses readline,
so I'll check and see what's happening over there.

> Note that I am working on the garbage collection scheme proposed
> by Toby Kelsey and Tim Peters.  Right now things are looking
> promising.  The cost seems to be quite low.  It can find almost
> all reference cycles that would occur in real programs.  Finally,
> it should be completely portable and does not require the use of
> a different malloc.  I will be posting the code to the Python
> patches list shortly.

Way cool!

waiting-for-python-1.7-with-the-ultra-snazzy-garbage-collector-ly y'rs, Z.
--
Moshe Zadka <mzadka@geocities.com>. 
INTERNET: Learn what you know.
Share what you don't.