This is the mail archive of the
guile@cygnus.com
mailing list for the Guile project.
Re: The taming of the before-gc-hook (was Re: Upcoming 1.3.2 release)
Jim Blandy <jimb@red-bean.com> writes:
> > Jim, we *need* at least one gc-hook on the Scheme level.
> > (We currently have the %gc-thunk.)
> >
> > Without it we loose the ability to get code executed when GC actually
> > happens. It would drain the power of guardians so that they become
> > *less* powerful than finalization.
>
> I actually think this is an advantage of guardians, not a
> disadvantage. The problem with finalizers is that they are called
> asynchronously; they can't make any assumptions about the state of the
> surrounding program. Guardians, on the other hand, can be invoked in
> a controlled way at known points in the program. Dybvig makes this
> argument in his paper.
Yes, guardians are nice in many respects, and should of course be the
default way of initiating action on objects that have been collected.
I'm sure there are many situations where an after-gc-hook is needed
(normal object finalization as described below, debugging, GC report
in a repl, etc.).
Imagine a library which produces objects which use some common
resource. When the objects are collected we want them to free their
use of the resource, just as happens in the free function of many
smobs.
Sure, we could specify in the interface that the user should call the
function `release' on the object when he is finished using it, but
then, what is the purpose of garbage collection?
Sure, we could specify a function `call-me-intermittently' which the
user calls repeatedly to release resources. Is this nice?
(OK, in many cases, this call could be placed in the object
constructor.)
In this case, I think the most natural solution is that the library
manages a guardian and puts a guardian harvester on the after-gc-hook.
The asynchronicity has to be tackled by the implementor of the
library, just as when he is using threads.
But then, what are the costs?
I'd say the only cost is that we have to specify in the manual entry
for the hook that it should be used with caution (it's not OK to run
too much code in it, so that a new GC starts; if this happens we could
detect it, clear the hook, and generate an error message).
No matter what we'll do in Guile in the future we'll always have a
garbage collector, and I'd say, no matter how it looks like, it will
always be possible to support an after-gc-hook (if the garbage
collector is incremental, we just call it once per sweep), so it
doesn't induce serious limitations on future implementations.
So, while I also prefer guardians, I'd say we should supplement them
with an after-gc-hook. We should do this since such a hook is
convenient in certain situations. It's not entirely clean, but useful
and robust if used correctly, and it doesn't cause problems for future
implementations. Or is there something I have missed?