[Python-Dev] Re: Suggested memory API rules for 2.3

Tim Peters tim.one@comcast.net
Wed, 03 Apr 2002 17:24:02 -0500


[Neil Schemenauer]
> Very good.  Spelling out the rules was long overdue.

That still needs to be done for PyObject_GC_xyz.  "Shall not mix", "shall
hold the GIL", "guaranteed binary compatibility", and "shall not use in
contexts requiring function designators" are the no-brainer answers.  Any
objections there?

>> Note that the eight ways to spell "free" all have to map to the
>> pymalloc free when pymalloc is enabled in 2.3.  There is no way to
>> spell "give me the raw platform free(), damn it", except for "free".

> I guess we need to do something special for pymalloc free() if
> PYMALLOC_DEBUG is defined.

I expect the simplest is to redirect all the "free" spellings to
_PyMalloc_DebugFree then; then I'll have to change that function to pass the
address on to system free() or _PyMalloc_Free(), depending on where the
address came from.  An alternative with some real attractions is to redirect
all "get memory" spellings to _PyMalloc_DebugMalloc in PYMALLOC_DEBUG mode,
in which case I'd need to change _PyMalloc_DebugMalloc to serialize via a
lock, and change _PyMalloc_DebugFree to serialize too and just *verify* that
all addresses passed to it came from _PyMalloc_Debug{Malloc, Realloc}.

>>     Recommended Practice
>> ...

> This should probably come up front in the documentation.  All the rest
> is historical crap. :-)

I agree, but this is Fred's call in the end.  In some ways the memory API
docs need to be more precise, but in others they need to give succinct
friendly advice about the least-hassle way to proceed.  Alas, the
compatability maze is so large it's bound to dominate the docs no matter how
it's rearranged.