RetroSearch Browse

Tue Oct 19 23:36:03 CEST 2004 · http://mail.python.org/pipermail/python-dev/2004-October/049504.html

[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).

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2004-October/049504.html below:

[Python-Dev] Changing pymalloc behaviour for long running processes