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

Michael Hudson mwh at python.net
Tue Oct 19 22:54:55 CEST 2004

Tim Peters <tim.peters at gmail.com> writes:

> In theory, the calling thread holds the GIL (global interpreter lock)
> whenever an obmalloc function is called.  That's why the lock macros
> inside obmalloc expand to nothing (and not locking inside obmalloc is
> a significant speed win).
> But in some versions of reality, that isn't true.  The best available
> explanation is in new_arena()'s long internal comment block:  because
> of historical confusions about what Python's memory API *is*, it's
> possible that extension modules outside the core are incorrectly
> calling the obmalloc free() when they should be calling the system
> free(), and doing so without holding the GIL.  At the time obmalloc
> last got a rework, we did find some extensions that were in fact
> mixing PyObject_{New, NEW} with PyMem_{Del, DEL, Free, FREE}. 
> obmalloc endures extreme pain now to try to ensure that still works,
> despite the lack of proper thread locking.  As the end of that comment
> block says,
> * Read the above 50 times before changing anything in this
> * block.
> Now all such insane uses have been officially deprecated, so you could
> be bold and just assume obmalloc is always entered by a thread holding
> the GIL now.  I don't know whether it's possible to get away with
> that, though -- if some "important" extension module is still careless
> here, it will break in ways that are all of catastrophic, rare, and
> difficult to reproduce or analyze,  If I could make time for this, I'd
> risk it (but for 2.5, not for 2.4.x), and proactively search for-- and
> repair --external extension modules that may still be insane in this
> respect.

Would it be possible to (in a debug build, presumably) do

assert(I have the GIL);

in PyObject_Free?


  If you don't have friends with whom to share links and conversation,
  you have social problems and you should confront them instead of
  joining a cultlike pseudo-community.    -- "Quit Slashdot.org Today!"

More information about the Python-Dev mailing list