[Python-Dev] Re: Suggested memory API rules for 2.3 (original) (raw)

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 PYMALLOCDEBUG 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.