[Python-Dev] Activating pymalloc (original) (raw)

Tim Peters tim.one@comcast.net
Fri, 15 Mar 2002 02:20:47 -0500

[Andrew MacIntyre]

My OS/2 build definitely uses threads (don't remember what FreeBSD ./configures to), and survives all the threading tests - which may not highlight the problems you're referring to.

Switching to pymalloc shouldn't be a correctness issue for code playing strictly by the rules. The historical problem is that the Python C API exposes more different spellings for "get memory" and "free memory" than you may believe possible, "the rules" for navigating this maze aren't documented, and so far all the spellings have reduced to plain "malloc" and "free".

So code cheating in any way has suffered no ill effects. People trying pymalloc have routinely reported hard-to-track-down problems, which have (so far) been traced to violations of the rules, and the explanation is always a surprise to the extension author ("I didn't know that!").

I believe all cases to date consisted of using specific "get memory" and "free memory" spelling pairs that aren't supposed to be used in tandem. It's also possible (well, it's more like inevitable) that some extension modules are calling these guys today when the global interpreter lock isn't held. Since platform malloc/free are generally threadsafe on their own, there won't be a hint of trouble until we turn on pymalloc (which currently relies on the GIL for thread safety).