[Python-Dev] Malloc interface (was: [Patches] Re: Garbage collection patches for Python (fwd)

[Vladimir Marangozov]

Fredrik Lundh wrote:
> 
> Vladimir Marangozov wrote:
> > The goal is to remove Python's dependency on the standard POSIX interface
> > (malloc/realloc/free) so that we can cleanly and easily plug in the future
> > a "proprietary" mem manager, other than the one in the C library.
> 
> (hmm.  I've been forced to use interfaces like this a lot, but
> never ever stumbled upon a situation where we couldn't just
> tweak malloc/free to mean what we wanted, either by relinking
> or via the preprocessor.  I'm sceptical, in other words...)

/F, I agree that it's "doable" via the pre-processor or by relinking.
But the truth is that this is not easy with the current code, and
"managing" to do it reveals special cases, spread all over the distrib.
It's about cleaning this up and settle on some rules which basically
make things explicit, than implicit. 

Beleive me, if you change Python's malloc to something else, all kinds
of troubles show up, especially with extension modules. And all you're
rewarded with is a segfault...

> 
> > For this purpose, the Python core should be patched and "cleaned" to use
> > one or more of the following APIs:
> > 
> > 1) PyMem_MALLOC        2) PyMem_NEW   
> >    PyMem_REALLOC  ==>     PyMem_RESIZE
> >    PyMem_FREE             PyMem_DEL
> >                           PyMem_XDEL
> 
> is XDEL simply a "if (p) free(p)" variant?

Yes, see mymalloc.h.

> 
> if so, don't forget that ANSI C requires that free() does the right
> thing if handled a NULL pointer.  since Python 1.6 will be ANSI C,
> it's probably better to force users of broken platforms to work
> around bugs in PyMem_FREE, rather than expose two different
> alternatives.  I'm pretty sure there are standard macros for auto-
> conf that tests for this.

I'm aware of this, but I think Guido has included PyMem_XDEL for 2 reasons:

a) it makes us foresee (and be explicit) that the pointer may be NULL
b) if the pointer is NULL, the cost of the function call is avoided.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252