a tentative design of a finalization mechanism for Guile

[Michael Livshin]

[ this is a proposal.  the use of "we" in the text below 
  indicates neither a consensus nor any kind of "definitive" status of 
  the design.  comments welcome. ]

* main goals

+ ease of use for clients, at least for the common case

+ ease of use for implementors, at least for the common case

+ some way of handling uncommon cases too

* overview

** general observations on finalization

+ object finalization is inherently a global phenomenon.  it has to do
  with the "liveness" of objects, and so is generally as hard to
  "localize" and approach in a "modular" fashion as memory management.

+ while finalization in general is hard, it appears that the common
  usage case is much simpler, and can, in fact, be made quite modular.

+ it also bears mentioning that in the relevant discussion on the GC
  list, nobody was able to come up with a real-life situation where a
  different finalization pattern was needed.  nevertheless, the
  consensus seemed to be that such situations are possible.  if I may
  speculate, I'll say that no such situation arised because all
  real-life programs are written in such a way as to make that
  impossible, since no adequate techniques (except guardians) exist to
  deal with it, and guardians are not implemented widely enough.

  (hmmm, ISTR someone commenting that the Java finalization is similar 
  to guardians.  anyone care to comment?  I don't do Java...).

** the common usage case

from the discussions on this list (and the GC list) it seems that the
common usage pattern of object finalization is quite straightforward,
and is characterized by the absence of cyclic dependencies and general
amenability to topological sorting of dependancies.  the most common
examples are the cleanup of file ports and pipes.

** why we still want guardians (or something similar)?

+ guardians allow us to perform the finalization in normal (non-GC)
  context, and offer the ability to "resurrect" objects.

+ guardians nave a nice interface (IMHO).

* the details (pretty sketchy at this point, as I'm soliciting
  comments)

+ two types of guardians: simple and topological.  topological are the 
  default.

+ global topological ordering of inaccessible objects.  there is an
  order relation between an inaccessible object A in a topological
  guardian and an inaccessible object B in any other guardian iff
  A references (maybe indirectly) B, or B references A.  there is _no_ 
  order relation between any two unaccessible objects if both are
  registered with simple (non-topological) guardians, even if one of
  them references the other.  note: the order relation between any two 
  inaccessible objects which are part of a cycle is unspecified.

+ an inaccessible object may be retrieved from its guardian iff
  there is no inaccessible object with a higher topological order that 
  has not yet been retrieved.

* possible complications

+ I don't yet know fully how to implement this stuff.  Dirk has some
  ideas, I need to read his post ;).

+ in a naive implementation, all guardian retrievals become
  synchronized.  I don't know whether it's a huge problem (I guess
  not), and a non-naive implementation is conceivable.

-- 
it takes more than not to remember how you did it the last time to be
innovative.                                            -- Erik Naggum