suzuki611 at okisoft.co.jp
Wed Jun 9 10:15:21 CEST 1999
| > 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
--===-----========------------- Sana esprimo naskas sanan ideon.
SUZUKI Hisao suzuki611 at okisoft.co.jp, suzuki at acm.org.
More information about the Python-list