Re: a tentative design of a finalization mechanism for Guile

[Michael Livshin]

address@hidden (Carl R. Witty) writes:

> If people are doing research on finalization mechanisms for Guile, I'd
> recommend reading:
> 
>  Stretching the storage manager: weak pointers and stable names in Haskell
>  (http://www.research.microsoft.com/Users/simonpj/Papers/weak.ps.gz)
> 
> They come up with mechanisms for finalization and weak pointers which
> they claim are preferable to guardians.

no really.  they came up with a kind of your regular async topological
finalizers ("regular": implemented by the Boehm collector and,
apparently, Smalltalk) with an interface geared towards the
implementation of weak hash tables; further complicated by the fact
that the finalizing function is stored together with the watched
object and needs to be scanned together with it.

they do claim that their finalizers are better suited for
implementation of weak (key) hash tables than guardians, but Guile
already has an implementation of weak hash tables which does not use
guardians and does not suffer from key-in-value problem. ;)

many thanks for the pointer, though.

please don't bother reading the "design" you followed up to -- not
only is it, er, strangely written (I was slightly drunk at the time
and it shows), it's also very very wrong in places.  sorry.

I guess we should just settle on Dirk's suggestion and implement
Boehm-style topological finalization through guardians.  the only
thing I'm not sure about right now is what to do with objects that are
guarded more than once (i.e. guarded more than once _themselves_, not
by virtue of being referenced by another guarded object).  thoughts?

-- 
===  ALL USERS PLEASE NOTE  ========================

The garbage collector now works.  In addition a new, experimental garbage
collection algorithm has been installed.  With SI:%DSK-GC-QLX-BITS set to 17,
(NOT the default) the old garbage collection algorithm remains in force; when
virtual storage is filled, the machine cold boots itself.  With SI:%DSK-GC-
QLX-BITS set to 23, the new garbage collector is enabled.  Unlike most garbage
collectors, the new gc starts its mark phase from the mind of the user, rather
than from the obarray.  This allows the garbage collection of significantly
more Qs.  As the garbage collector runs, it may ask you something like "Do you
remember what SI:RDTBL-TRANS does?", and if you can't give a reasonable answer
in thirty seconds, the symbol becomes a candidate for GCing.  The variable
SI:%GC-QLX-LUSER-TM governs how long the GC waits before timing out the user.