[Python-Dev] Changing pymalloc behaviour for long running
processes
Tim Peters
tim.peters at gmail.com
Tue Oct 19 23:36:03 CEST 2004
[Michael Hudson]
> Would it be possible to (in a debug build, presumably) do
>
> assert(I have the GIL);
>
> in PyObject_Free?
There's no canned way to do this. I suppose it could call
PyGILState_Ensure(), then assert that the return value is
PyGILState_LOCKED. PyGILState_Ensure() has to do a lot of work to
figure out whether its calling thread has the GIL, and needs access to
pystate.c internals to get the right answer; I expect simpler
approaches are doomed to fail in some cases.
If we changed the PyMem_Free spellings now (for 2.5, not *now* now
<wink>) to call the system free() instead in a release build, the
thread craziness obmalloc is trying to protect against would just go
away by magic.
It would be good to do the assert() you suggest anyway, but for a
different reason then (catching unsafe calls in debug builds, where
all of the PyMem family ends up in obmalloc).
More information about the Python-Dev
mailing list