[gclist] Some different thinking on finalizers.

[Giuliano Carlini]

Charles Fiterman wrote:
> 
> 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++.
> 
> I'm not totally gung-ho on the prompt part except for file handles.

I've heard 2 reasons for desiring prompt finalization:
	- Limited resources ala' Charle's O/S file handles
	- Prompt reaction to some event
I've had to deal with both when I added a GC to an existing large
C++ program.

The first is really a problem of the O/S or environment. But, for GC's
to
be accepted, they must deal with problems created by other subsystems.
This can often be handled by writing a class which multiplexes
the limited resource. E.g., write a file class which is
implemented using the limited O/S file handles. If a new file object
is created, and all file handles are in use, select the least recently
used
file, stash the file handles state, close the file, and reopen it for
use
by the newly created file object. To be sure, this is a real pain in the
neck. And it can't be used in some cases where the limited resource
communicates with some other software: A file handle locking a region of
a
file, a semaphore, etc. Even though it isn't a universal solution, it
helps quite a bit.

The second is a non problem. I'll discuss a couple of examples that have
been presented to me as problematic:
	- releasing the window handle for a GUI window when the user
		presses the close menu item
	- releasing a semaphore when its critical section is exited.
The solution is to separate "local finalization" from object
finalization.
Local finalization for the above examples are:
	- Hide the window, but do not destroy the GUI window handle.
	- Release the semaphore, but do not destroy the semaphore handle.
This is all that must be done immediately. Do no more. In this way,
these
objects can safely be used by any other references. When all references
have
disappeared, then object finalization can be done:
	- Destroy the GUI window handle
	- Destroy the sempahore handle

Lastly, Charles is right about the guarantee of finalization. Some
things
must be done to maintain system invariants.

g