Python 2.0

Hisao Suzuki suzuki611 at
Wed Jun 9 10:15:21 CEST 1999

| >[Salvador]
| > I have been using Java since it was invented and I haven't programed a
| > finaliser ever. They should run under so unknown and inconsistent
| > environment that they are not usable at all (except for freeing external
| > resources).

I have not ever programmed any finalizer, too, while I have
programmed a lot of codes in Java.

| [Graham Matthews]
| > I am not sure I understand this. Can you explain to me how a finaliser
| > can run in an unknown environment. Surely everything the finaliser needs
| > is referenced by the finaliser (either directly or indirectly) and hence
| > is still there.

| The caveats are explained well in the Java Language Spec, section 12.6.
| ...

| All Java defines is enough so that the Java runtime itself never chokes on
| e.g. an internal null pointer, i.e., your "still there" guarantee.  Say you
| have a mail server holding a ref to a mail client, which in turn holds a ref
| back to the mail server.  Can the client object tell the server it's going
| away at finalization time?  Not if the server object shut down the
| communications link beforehand because the server's finalizer happened to
| get called first.  Etc.  Yes, the references are "still there", but without
| a lot of pain there's no guarantee they're still in a *useful* state.

It would be an issue of distributed garbage collection.  And it
is a difficulty for automatic GC with finalization.  In
addition, perhaps we should also take a (close) look at

It summarizes other (or rather more general) issues to consider
in the design of a finalization mechanism (and presents one
solution for Scheme---actually it is adapted by gnu guile).  I'd
think anyone who is planning improvements on Python's storage
management has to _notice_ what are summarized there first.
(The solution is another story.  It is not so obvious for

# Certainly the current reference counting system of Python
# reduces the issues to fairly (though _not_ fully) tolerable
# ones...

--===-----========------------- Sana esprimo naskas sanan ideon.
SUZUKI Hisao            suzuki611 at, suzuki at

More information about the Python-list mailing list