fork()

[Guido van Rossum]

> From: "Tim Peters" <tim_one at email.msn.com>

> In this kind of approach, I doubt there's a substantially better way.  Guido
> will also want a doubly-linked list (where the links don't count against the
> refcount!) so that when a dict goes out of existence via the normal
> refcount-hits-0 route, the dict can efficiently unlink itself from the list.

Probably, although everytime this comes up I try to figure out a
clever scheme to use a singly-linked list, where the zero-refcnt ones
are recycled at the next mark-and-sweep.

> So, ignoring that, you make one pass over the trash list just to run
> finalizers.

Bzzt!  We only have a trash list of dictionaries.  The finalizers are
typically on class instances (or extension type objects) that are
somehow referenced by those dictionaries!  But not every object
reachable from a trash dictionary is trash, of course.  Nasty... :-(

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.

--Guido van Rossum (home page: http://www.python.org/~guido/)