[Openmcl-devel] make-record malloc/free question

[Cyrus Harmon]

This is what I was looking for. Thanks for the pointer. I'm pretty 
comfortable with the restrictions on the malloc'ed memory object, but 
the "termination" stuff is what I think I need.

As for make-record, I, naively, assumed that when the value returned by 
make-record was gc'ed, it would #_free the memory for me. I can 
understand why this might not be a good idea, but it might make sense 
to do one or more of the following:

1. #_free the malloc'ed memory when the value is gc'ed

2. provide a destroy-record function #_frees the malloc'ed memory

3. Change the make-record documentation to tell users of make-record 
that they need to #_free the memory when they're done with it.

I know it's ugly living in a mixed lisp/non-lisp memory environment, 
but the alternative (not calling foreign code) seems worse.

I'll see if I can make this work for me. I gather this whole 
termination/finalization(which unfortunately means something else in 
MOP terms) is (was?) a recurring issue on the flame war battlegrounds, 
but it's too bad (IMHO) that this isn't part of the language spec, 
rather than an implementation "feature".

Thanks,

Cyrus

On Aug 19, 2004, at 2:26 PM, Gary Byers wrote:
> (defmethod initialize-instance :after ((x encapsulating-object) &rest 
> initargs)
>   (ccl:terminate-when-unreachable x))
>
> (defmethod ccl:terminate ((x encapsulating-object))
>   (with-slots (foreign-pointer)
>     (when foreign-pointer
>       (#_free foreign-pointer)
>       (setq foreign-pointer nil))))
>
> The CCL:TERMINATE method will be called on some arbitrary thread
> sometime (hopefully soon) after the GC has decided that there are no
> strong references to an object which has been the argument of a
> CCL:TERMINATE-WHEN-UNREACHABLE call.
>
> If it makes sense to say that the foreign object should live as long
> as there's lisp code that references it (through the encapsulating
> obect) and no longer, this is one way of ensuring that.
>
> (What OpenMCL calls "termination" is essentially the same as what
> Java and other languages call "finalization".)