[Patches] Re: Garbage collection patches for Python
Moshe Zadka <email@example.com>
Thu, 10 Feb 2000 07:47:04 +0200 (IST)
On Wed, 9 Feb 2000 firstname.lastname@example.org wrote:
> > 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.
waiting-for-python-1.7-with-the-ultra-snazzy-garbage-collector-ly y'rs, Z.
Moshe Zadka <email@example.com>.
INTERNET: Learn what you know.
Share what you don't.