[Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361)

[Vladimir Marangozov]

Greg Stein wrote:
> 
> On Sat, Jun 17, 2000 at 10:53:20AM +0200, M.-A. Lemburg wrote:
> >...
> > Perhaps we ought to add some code which takes care of cleaning
> > up all remaining garbage left over after the call to
> > call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing
> > of all interned strings and cached ints/floats and associated
> > free lists or dicts.
> > 
> > We'd need new APIs in string|float|intobject.c to implement this.
> > 
> > Thoughts ? Patches ?
> 
> I would definitely like to see this, and suggested it to Guido about four
> years ago :-)
> 
> During my threading work, I looked at all the globals, which includes the
> pools and the one-off allocations in classobject.c and friends. I figured it
> would be a Good Thing(tm) to write a general object pool API which could be
> used by tuples, floats, frames, etc. Having the single implementation of a
> pool would mean that we could add thread locks in a single place.
> 
> Similarly, for cleanup reasons, I also suggested a general API for
> allocating the "constants" and torching them at shutdown.
> 
> As we all know, though... suggestions don't mean crap. Code counts. :-)

pymalloc (the debugging stuff put aside) is an efficient implementation
of this pool concept. The interface just needs to be exported under an
appropriate PyObject_ API, not as a general malloc replacement. Maybe
it needs some more work regarding finalization, but the code is there.
Per pool locking is there too. Maybe it needs to be adjusted wrt the
pool granularity we want.

The various core object allocators would use this API with PyObject_NEW
inlined.

> 
> That said, I'll look into some of this with the free-threading work. That is
> all post-1.6, though. It would be great if somebody could do it before then.

Voila.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252