fork()

[Tim Peters]

[Tim]
> What you suggest is weaker, effectively lumping the SCCs into two gross
> classes (singletons and non-singletons), and nuking the latter first.

[Evan Simpson]
> Sorry if I was unclear, but that's not what I meant by "dangly bits".
> Rather, take the set of nodes from which you cannot reach a cycle.  Their
> subgraph is a union of DAGs, which can be released normally.  In your
> example, handing "c" a reference to "d<->e" converts it from a
> dangly bit to a cycle-bridge.

Ah, pulling the old DB-to-CB trick <wink>.  I can't say for sure whether you
were unclear before, but it's clear to me now.  Thanks!

> On the other hand, the SCC approach does look stronger than this, since it
> can handle cycle-bridges as well.  I'll happily take your word that
> SCC-counting is likely to be too much trouble, but how about just doing an
> SCC-analysis once M&S has discovered a cycle?  If this is all happening in
> the background, with no deadlines, and with rare, naughty data structures,
> then it doesn't have to be terribly efficient.

Well, we can *never* "win".  The instant the "why aren't my cycles
collected?" complaints go away, the "why does collecting my cycles take so
bloody long?" complaints arrive.  Note that the strongest proponents of GC
over the years here have not, like the Perl camp, been worried about
accidental cycles slowly piling up in long-running servers -- they're keen
to create cycles all over the place.

So slow won't fly forever.  That said, identifying SCCs can actually be done
quite efficiently; making an exact accounting of inter-SCC pointers is
harder but still not a killer.  I'm more bothered by the (lack of) *sense*
in it all:  ignoring a __del__ method on an object that has one is darned
hard to justify, yet Python can't (any more than Java can!) do anything
sensible with __del__ in cycles on its own.

So my plan for the hour <wink> is:  if M&S finds a cycle, it will clean it
all up iff no involved object has a __del__.  If an object in a trash cycle
does have a __del__, tough, the cycle won't be reclaimed.  Instead we'll
supply a function you can call if you care, that will return those objects
(one at a time?  in a list?  whatever), and you do with them what you will;
if you don't clean them up, you'll keep getting them back every time you
call that function until you resurrect them or break the cycle by hand in
the way that makes most sense to your algorithm.

In the face of ambiguity, refuse the temptation to guess <0.5 wink>.

dear-lord-now-he's-quoting-himself-ly y'rs  - tim