[gclist] Destructor FAQ

[Amit J Patel]

Hans Boehm wrote to me on March 7:
> 
> Invoking all finalizers at program exit is tricky, since there is no way to
> order the calls to ensure that finalized objects can't be referenced.  I'm
> actually not convinced that this is very interesting IF the operating system
> is doing its job and cleaning up resources on process exit.  (And I don't
> believe that an OS can be reasonably robust without doing that.)  Thanks to
> Microsoft and a few other vendors, it does seem to be interesting in some
> contexts.  I would prefer to see the user maintain (the right kind of) weak
> pointers to these objects and clean them up explicitly at program exit, if
> necessary.

If I understand you correctly, you are suggesting that the programmer
write a routine that scans weak pointers regularly; if a pointer is set to
nil, then a cleanup routine would be invoked for that object.  At
program exit, the remaining cleanup routines would be called.

My main objection is that I don't want to clutter module A's code with
periodic calls to module B's scanning routine.  In fact, I don't want
to clutter module A's code with calls to its own scanning routine
either.  (It reminds me of Macintosh and Windows 3.x programming,
where one must call a system routine during long processing to make
sure events get handled.)

Would it be feasible for the garbage collector to maintain a list of
functions that must be called AFTER a collection?  That would the
right time to check for cleanup, and it would also free me from having
to explicitly call the cleanup function.  Every time new data is
added, it could register a cleanup function with the GC.  (Is this
getting back to finalizers?)


	- Amit


-- 
Amit J Patel, Computer Science Department, Stanford University