MOP questions (was Re: [Openmcl-devel] byte-strings)

[Gary Byers]

On Tue, 7 Sep 2004, Ben wrote:

>
> On Tue, 7 Sep 2004, Gary Byers wrote:
>
> > A hash table can be "weak on key" or "weak on value"
>
> great -- thanks for the info and the example.
>
> > MAKE-HASH-TABLE accepts a :FINALIZABLE keyword argument, but I believe
> > that it completely ignores it: keys/values aren't automatically
> > scheduled for termination.  (It's possible to call
> > CCL:TERMINATE-WHEN-UNREACHABLE on the object in question; if the
> > :FINALIZABLE keyword mechanism worked - I broke it a long, long time
> > ago - the GC would do this automatically.)
>
> sorry, i'm not sure i understand, does this mean that general
> finalizers are not available?
>

Any allocated object can be scheduled for finalization via
CCL:TERMINATE-WHEN-UNREACHABLE.  (This is documented; Dan Knapp said
that he wanted to move the documentation out of the FFI section and
into something more general soon.)

If the :FINALIZABLE option to MAKE-HASH-TABLE worked, it would do
something like CCL:TERMINATE-WHEN-REACHABLE for you (between the time
that the weak component of a pair is added and the time that it's
removed by the GC.)  As it is, you have to do that manually.  Assuming
that *WEAK-HASH-TABLE* is weak on key (as in the earlier example):

? (defclass thing ()
    ())
#<STANDARD-CLASS THING>
? (defmethod ccl:terminate ((x thing))
    ;;; This method will be called on some thread, soon after the
    ;;; GC notices that X is about to become garbage.
   (format t "~&There's now one less thing to worry about: ~s" thing))
#<STANDARD-METHOD CCL:TERMINATE (THING)>
? (let* ((some-thing (make-instance 'thing)))
    (ccl:terminate-when-unreachable some-thing)
    (setf (gethash some-thing *weak-hash-table*) 17))
17
? (gc)
NIL
?
There's now one less thing to worry about: #<THING #x638A4D6>

The CCL:TERMINATE method should run "soon" after the GC finishes; whether
it's before or after the listener printed the NIL and its prompt isn't
predictable.  The method runs in an arbitrary thread (currently the
one that's running the periodic "housekeeping" loop, but that could
change): the method shouldn't assume much of anything about its dynamic
environment.