[Python-Dev] Re: DEBUG_SAVEALL feature for gc not in 2.0b1?

[Vladimir Marangozov]

Neil Schemenauer wrote:
> 
> On Fri, Sep 01, 2000 at 11:47:59PM +0200, Vladimir Marangozov wrote:
> > By putting them in gc.collected_garbage. The next collect() should be
> > able to empty this list if the DEBUG_SAVEALL flag is not set. Do you
> > see any problems with this?
> 
> I don't really see the point.  If someone has set the SAVEALL flag then
> they are obviously debugging a program.  I don't see much point
> in the GC cleaning up this garbage.  The user can do it if they like.

The point is that we have two types of garbage: collectable and
uncollectable. Uncollectable garbage is already saved in gc.garbage
with or without debugging.

Uncollectable garbage is the most harmful. Fixing the program to
avoid that garbage is supposed to have top-ranked priority.

The discussion now goes on taking that one step further, i.e.
make sure that no cycles are created at all, ever. This is what
Skip wants. Skip wants to have access to the collectable garbage and
cleanup at best the code w.r.t. cycles. Fine, but collectable garbage
is priority 2 and mixing the two types of garbage is not nice. It is
not nice because the collector can deal with collectable garbage, but
gives up on the uncollectable one. This distinction in functionality
is important.

That's why I suggested to save the collectable garbage in gc.collected.

In this context, the name SAVEALL is a bit misleading. Uncollectable
garbage is already saved. What's missing is a flag & support to save
the collectable garbage. SAVECOLLECTED is a name on target.

Further, the collect() function should be able to clear gc.collected
if it is not empty and if SAVEUNCOLLECTED is not set. This should not
be perceived as a big deal, though. I see it as a nicety for overall
consistency.

> 
> I have an idea for an alternate interface.  What if there was a
> gc.handle_garbage hook which could be set to a function?  The collector
> would pass garbage objects to this function one at a time.

This is too much. The idea here is to detect garbage earlier, but given
that one can set gc.threshold(1,0,0), thus invoking the collector on
every allocation, one gets the same effect with DEBUG_LEAK. There's
little to no added value.

Such hook may also exercise the latest changes Jeremy checked in:
if an exception is raised after GC, Python will scream at you with
a fatal error. I don't think it's a good idea to mix Python and C too
much for such a low-level machinery as the garbage collector.

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