This is the mail archive of the
mailing list for the Guile project.
Re: The taming of the before-gc-hook (was Re: Upcoming 1.3.2 release)
- To: firstname.lastname@example.org
- Subject: Re: The taming of the before-gc-hook (was Re: Upcoming 1.3.2 release)
- From: Telford Tendys <email@example.com>
- Date: Mon, 2 Aug 1999 11:48:43 +1000
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
> > To support encapsulation I think guile should (no *must*) support a
> > per object finit function. Maybe as an option.
> > For example:
> > scm_set_finit(object, free) /* call free befor object is free'ed */
> > (Mabe this is already available?)
> No, and, sorry, it is too expensive.
Would it be difficult to make an SMOB that contains exactly one SCM
object and one (lambda (x) ...) that acts as a finit function?
Since the SMOB naturally gets a chance to clean itself up it could call
the lambda to clean up resources in the SCM object. This would be
a bit hairy depending on the SMOB to get cleaned before the cells that
it might link to get reused, dunno how difficult that might be for
Anyhow, if such a thing was done then normal eval would be the same
speed and anyone who needs such a function could wrap one in this
type of SMOB (sacrifice speed and memory only in cases where the
facility is needed). Mind you, this is getting kind of similar to a guardian
anyhow, the main difference would be that with some tweaking, maybe one
of these SMOBs could allow transparent access to its contents (i.e.
get used as a normal SCM object itself). This would depend on the
lambda getting set at time of creation and never changing.
Just an idea...