[Patches] PyMem [2/8] - Include/mymalloc.h

Vladimir Marangozov Vladimir.Marangozov@inrialpes.fr
Thu, 4 May 2000 11:41:01 +0200 (CEST)


Guido van Rossum wrote:
> 
> Suggestion:
> 
> Include instructions for using your own allocator -- what you need to
> change, what you need to implement, what rules you need to play by.
> (Is there only one level where you can substitute your own?  Or more?)

Okay, will do. A scenario might help:

1) Scenario A

Suppose we want to use a debugging malloc library that collects info
on where the malloc calls originate from. Assume the interface is:

d_malloc(size_t n, char* src_file, unsigned long src_line) c.s.

In this case, we would define (for example in config.h) :

#define PyCore_MALLOC_FUNC      d_malloc
...
#define PyCore_MALLOC_PROTO	Py_PROTO((size_t, char *, unsigned long))
...
#define NEED_TO_DECLARE_MALLOC_AND_FRIEND

#define PyCore_MALLOC(n)	PyCore_MALLOC_FUNC((n), __FILE__, __LINE__)
...

2) Scenario B

For some reason, we want to use malloc hooks (defined & initialized in a 3rd
party malloc library) instead of malloc functions.  In this case, we would
define:

#define PyCore_MALLOC(n)	( (*malloc_hook)(n) )
...

and ignore the previous definitions about PyCore_MALLOC_FUNC, etc.

> 
> Questions:
> 
> Do we really need to have even b/w compat macro support for
> Py_Malloc()?  I think it's cleaner to fail with an error during
> compilation or linking than to silently mess up things when someone
> calls it expecting that it will raise an exception where in fact it
> won't.  I've deleted it.  And also PyMem_XDEL, for the same reason.

I leave this to your appreciation.
It's about breaking/fixing 3rd party extensions...

> 
> Should the PyCore_* names be _PyCore_* to indicate they are for
> internal use only?

Maybe.

> When *is* it okay to use them?

In a custom memory manager, not in user's code. They are supposed to be
defined/overloaded in config.h whenever a custom allocator is used.
They should never appear in the usual Python-related C code.
In low-level memory management code, yes (or maybe, depends on the needs)

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