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

[Greg Harvey <Greg.Harvey@thezone.net>]

Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se> writes:

> OK, that didn't score any points, did it?

That's not it, I didn't have a chance to read it before you followed
up ;'). 

> Let me put it differently:
> 
> Using a special registration function and mechanism for the
> before-gc-hook is certainly one possibility, and, maybe it is the most
> easily maintainable in the long run.
> 
> I'd like to propose two additional alternatives:
> 
> 1. The C programmer sees two hooks
> 
>       scm_before_gc_hook
>       scm_after_gc_hook
> 
>     to which he can attach his C functions (wrapped as a subr).
> 
>     The Scheme programmer sees only after-gc-hook (which is in fact
>     the hook stored in scm_after_gc_hook).
> 
> This is as safe the special registration function alternative, but the
> user interface is more symmetric and less code is required to
> implement it.

I think this is the best way to go. I wasn't entirely sure exactly
what could cause allocation in the evaluator, which was making me a
bit weary of using hooks.

I don't like the approach of reserving cells and allowing scheme code,
because it's pretty much impossible to make it robust (it's different
from reserving cells for threads, because there we can always garbage
collect if we run out), and the benefit really isn't that great
(considering the fact that it does make things more fragile, and does
add a small amount of complexity to the garbage collector); either the
hook is used for a simple notification mechanism, which is just as
easy to write in c as scheme, or it's being used for munging data
structures to prepare for a collection, which is something you'd
probably be doing in c, anyway.

-- 
Greg