[gclist] Some different thinking on finalizers.
Charles Fiterman
cef@geode.geodesic.com
Wed, 02 Oct 1996 12:38:46 +0100
At 12:43 PM 10/2/96 -0400, you wrote:
>
>I must admit that I am still puzzled by this insistence that finalizers
>run promptly. I think it is a request that cannot easily be granted,
>that warps the rest of the system, and that is not necessary anyway.
>I also wonder if this is an artifact of too much use of C++.
>
>The reason I say this is that I recently did some non-play programming
>in a language with non-prompt GC-finalization, but that also had
>TRY-FINALLY-END blocks. The application was a limited-purpose web
>server -- it accepts *CODE* from the net, compiles it, and runs it,
>all for demonstration purposes. We care about security and audits,
>and we care about not crashing, because the people on the other end
>are potential customers, except for the ones that want to try to
>break in for "fun".
I'm not totally gung-ho on the prompt part except for file handles.
After all if you are on a system that allows 20 file handles you
better finalize them promptly.
But the sure part is a requirment. And the sure part means you
can use finalizers to insure correctness. You can say if we
get to A we must run B. That vastly improves the utiltiy of
finalizers.
I'm willing to live without prompt, but not sure. And the only
way I see to guarantee sure is to say finalizers must not violate
an objects invariants. Tell the programmer that finalizers may
run in any order. If you don't like it there are ways you can
keep things alive.
Charles Fiterman Geodesic Systems
Phone 312-728-7196 4745 N. Ravenswood Suite 111
Fax 312-728-6096 Chicago Il 60015
A language without garbage collection is
like a city without garbage collection.