Re: Reasons, why Miss Scheme should collect her garbage before shutdown.

[Matthew Flatt <mflatt@cs.utah.edu>]

Quoting Sebastian H Seidel:
> - Often it is useful to bind the lifetime of an external object to a
> lexical scope inside the Scheme-Environment, like so:
> 
> (let ((obj (make-external-object args)))
>    (operation-on-external-object obj)
>    ...)

Probably we agree that `make-external-object' should register the
external object with the current custodian. Then, when the user clicks
"Execute" in DrScheme, the external object is cleaned up immediately.

With scheme_add_atexit_closer(), custodians solve the problem
completely. There's no need to go into the murky waters of GC
behavior...

> - a buffer could be created which in the end must be written to a file
> or
> - some kind of communication could be started which in the end must be
> terminated by special commands or 

These jobs should *not* belong to finalizers or custodian-shutdown
procedures. Sending an end command or flushing a buffer involves
considerable work that potentially blocks the process, and such work
shouldn't be buried in GC or in the termination mechanism.

> Finalizers are both a very useful and versatile means to put a
> controlled end to each object,

But with lots of problems.

How many GCs are you willing to perform before exiting? It's easy to
create a long chain of objects where only one finalization can occur
after a GC.

Simply running all finalizers won't work, because some finalizers may
need to use objects that themselves have finalizers. Picking an order
to run the finalizers amounts to GC.

And if you don't order the finalizations at all --- in other words,
don't tie it to GC? That's a custodian-shutdown procedure.

> Best solution
> -------------
> MzScheme is changed so that she does collect her garbage before
> exiting.
> [...]
> 
> Why not go for the best and most clean solution?

Even ignoring the inherent problems of finalizers, it's prohibitively
difficult to define garbage collection precisely enough in MzScheme
that it could be used for general resource management.

To put it another way: garbage collection works because we have lots of
memory to work with, and the imprecion is invisible (in the absence of
finalizers!); if we squander a bit of memory, it's usually no tragedy.
File descriptors and other resources are far more precious, and the
imprecision tends to be visible (e.g., to the other end of the
descriptor).

Arguably, the problem is with MzScheme's implementation, not the idea
of garbage collection (at least if we suspend disbelief about the value
of finalizers). But the more I look at the problem, I'm actually not so
sure. Although we've wrestled with memory problems in DrScheme that
would be problems with any Scheme+GC implementation, custodians are
especially easy to use. For managing precious resources in a large
application, you want to make the programmer's reasoning job easy, and
I don't see that ease-of-reasoning in GC.

--------------------

So, will MzScheme perform a GC on exit in the future? No, because it
isn't reliably useful.

I'm less certain about scheme_add_atexit_closer(). Maybe a programmer
shouldn't have to do extra work to request a custodian-based shutdown
on exit. Instead, all custodians would be shut down on exit. But that's
lots of unnecessary work in most settings.

Matthew