This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: The taming of the before-gc-hook (was Re: Upcoming 1.3.2 release)



> 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.

The whole question of finalization is a very controversial one.  It's
difficult to define finalization in a way that gives the finalization
code enough invariants to establish its correctness while still doing
something useful.  There are no proposals that make everyone happy.
Guardians are the cleanest proposal I know of, and seem sufficient for
most purposes.

Also, I don't agree that such hooks are necessary.  Emacs has gotten
by for years with no such hooks.  Common Lisp doesn't provide them, as
far as I can see.

C-level hooks allow the SCWM folks to do what they need to do.  I'm
pretty confident that Maciej and Greg will use them tastefully.


To address Harvey's question:

Certainly, a C-level hook can do dangerous things, and can call
dangerous functions --- in fact, it has more dangerous potential than
a Scheme-level hook, since it could invoke the interpreter itself.

But in Guile, C code is written at a level that gives the programmer
*control* over these issues, so it is reasonable and fair to make the
programmer responsible for doing the right thing.  Scheme code gives
the programmer no control over whether dangerous operations occur ---
the programmer is at the mercy of the implementation.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]