GC interface (was Re: Scheme hooks <-> C hooks)

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Michael Livshin <mlivshin@bigfoot.com> writes:

> Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> 
> > Guile also needs to provide them in the API because we want to be
> > able to write external modules providing new types of objects with
> > special GC behaviour (similar to guardians and weak vectors).
> 
> this would require somehow formalizing what info is available at each
> stage of GC, how it is available, what can you do with it, etc.  which
> is OK, except I don't think it can ever be a stable API.  oops, that
> acronym again...

Well, I've not said that the GC hooks (scm_before_mark_c_hook et al)
should be part of the standard API.

They could be regarded as part of a GC interface intended for
extending the current collector, provide modules using objects with
special GC behavior, etc.  (I have a matrix library prototype which
re-uses storage for matrices.)

The things such modules need to care about are the GC mark bits, and
to use special versions of the pair selectors when traversing list
structures.

The hooks are placed at well-defined (as long as you only care about
mark bits) places in a mark-and-sweep collector.


However, the C hook facility seems generally useful.