[gclist] Finalization and the insane postman bug.

[rog@vitanuova.com]

this discussion makes me quite glad that we haven't got generalised
destructors in Limbo; it uses a combination of refcounted and
mark&sweep GC (if garbage isn't cyclic then it goes away immediately),
and destructors are available to the Inferno kernel, which uses them
in a limited way to free some kernel-level resources (e.g.  open
files, windows).  these destructors run synchronously, but as they're
a well defined finite set, we don't come across the same problems that
Hans talks about.

every so often the subject comes up: "wouldn't it be nice to have
general destructors?".  we invariably conclude that they're more
trouble than they're worth.

in my view, the two "killer" points being:

	o in what context will the destructor run?
		in this case we're talking about an OS, not just a
		language; processes have all sorts of context (e.g.
		open files, user id, file namespace) but the heap is
		shared between all of them, and the program that
		created a heap object isn't necessarily around to
		oversee its destruction.

	o would we be able to understand the code?
		having arbitrary code invoked (synchronously or
		asynchronously) as a result of
			a = b;
		seems to me to be begging for hard-to-find and
		hard-to-fix bugs.  hans's example is the thin end of
		the wedge, i suspect.

the language has concurrency primitives (CSP-like message passing)
built in, and i had previously toyed with the idea of registering a
channel with an object; when the object gets destroyed, a value is
sent down the channel (not the object itself), kind of like
cef@geodesic.com's "death note".  thus the "death note" is received in
a well-defined context (a user level process created for the purpose).

however the points made with regard to being unable to bound the time
of execution of a finaliser method apply equally in this case.  when a
load of objects get destroyed, they'd queue up in some fashion, and if
one finaliser blocks, the notification of all the rest blocks too,
unless some highly elaborate scheme involving timeouts and god knows
what is implemented.

my inclination is just to bow out of the whole argument.

do we really need general finalisers?

    rog.