[gclist] Destructor FAQ

[Bill Bill]

|   Sender: owner-gclist@iecc.com
|   Date: Thu, 7 Mar 1996 11:25:06 -0800
|   From: Mario.Wolczko@Eng.Sun.COM (Mario Wolczko)
|   Sender: owner-gclist@iecc.com
|   Precedence: bulk
|   Reply-To: gclist@iecc.com
|   Errors-To: owner-gclist@iecc.com
|
|   Nobody has mentioned post-mortem finalization in any detail, so I'll
|   throw in a paragraph or two...
|
|   David Gadbois's contribution on destructors mentioned possible problems
|   when GC systems also incorporate finalization.  Post-mortem
|   finalization attempts to solve these problems.

I may be confused, but how does this solve the ordering problem in the
mutator?  In other words, how does the mutator then guarantee that the
buffers are flushed before the OS-level file handle is closed, when
both are independently finalized?

The MIT Scheme implementors played with several such solutions and
designs and we were never satisfied with any because of the order or
precedence problem.

It seems to me that in general such dependences must be made explicit
to the "finalization manager", which must do a topological sort (God
help it if there are cycles), and finalize in that order.

In other words, it seems to me that when an object is "declared for
finalization", the objects on which it depends (and which presumably
are also pointed by it) must be declared as well.

E.g.:

  declare_finalization (object, finalization_handler, object*)

Where object must be finalized _before_ the object* are finalized.

Graphs can be detected (expensive!) when the finalization is declared,
and the call can be rejected indicating to the caller that a cycle
would have been introduced by the new link.

For a simple hierarchical situation (e.g. proper layering of buffered
streams on top of simple streams on top of file handles) there would
be no issue.  I don't know if there are situations that require the
cycles, however, and I have no idea what could be done then.