fork()

[Evan Simpson]

Sounds good to me, if the mechanism reports/logs cycles in such a way that
you can figure out how to cleanly break them or avoid making them in the
first place (#10 Errors should never pass silently).  Perhaps I'm being
naive, but I have the impression that when cycles arise it's usually a
simple accident and easy to fix once you know you've done it.  The hard part
is noticing that you've pinched one off, yes?  If a cycle is really hard to
eliminate without contorting your code, you could make an explicit decision
to allow it to be collected and make sure the affected objects don't need
finalization (#11 Unless explicitly silenced).

Would it be possible (and not too expensive) to distinguish actual cycle
members from dangly bits (maximal non-cyclic subgraphs)?  If so, it might be
worth releasing the dangly bits normally through their root object after
flushing the cycle.  That way you could have cycles in a program yet still
have a place to put resource finalizers.

Tim-will-regret-those-20-Theses-yet-ly y'rs
Evan Simpson

Guido van Rossum wrote in message
<199906110443.AAA02408 at eric.cnri.reston.va.us>...
Could we get away with not calling (user) finalizers on objects in
trash cycles at all?  Since the finalization order is problematic at
best, this almost seems acceptable: in the formal semantics, objects
that are part of cycles would live forever, and as an invisible
optimization we recycle their memory anyway if we know they are
unreachable.  (I've got the feeling that I've seen this rule before
somewhere.)  We'd still get complaints "my __del__ doesn't get called"
from some users, and the answer would still be "it's in a cycle -- use
an explicit close"; but those who know what they are doing can be
guaranteed that their memory cycles get recycled.  In other words it
would be no worse than today and for some people it would be better.