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

[Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se>]

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

> However, I do like the idea of using hooks from all other aspects.
> And I think it's a good idea to try hard to get rid of extra
> mechanisms for specific purposes.
> 
> What about reserving a pool of conses which is made available to
> NEWCELL during special conditions like this?  (There's still the
> problem with malloced memory.)  The size of this pool could be a
> settable parameter.
> 
> Also, note that if only well-behaved C functions, wrapped as
> scm_tc7_subr_0:s, are added to before-gc-hook, no conses will be used,
> so it's still possible to use the hook mechanism.

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

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.

(wilder)
2. Same as 1 but the Scheme programmer also sees the before-gc-hook.

The advantage is obvious.  The disadvantage is that we have to reserve
a pool of conses for special uses (it could be used for other purposes
as well, like printing objects during debugging).  Another
disadvantage is that we would have to warn the user about what is safe
to put in this hook, making the interface more complex.

Note that it is possible to arrange for the before-gc-hook to abort
nicely and quietly (meaning that GC will proceed) if we run out of
memory.

Personally, prefer 2 because it gives more power and possibilities.
Concerning the complexity argument, I'd say that there are other parts
of the interpreter where it is more important.