[Openmcl-devel] Using Cocoa with MCL

[Gary Byers]

On Thu, 8 May 2003, Sven Van Caekenberghe wrote:
>
> A point that I missed in this discussion is how to map the cocoa memory
> management to a full gc'ed world. I always wondered how they do it in
> the objc-java bridge. What I hate about objc/cocoa is this stupied
> retain/release stuff - could we make it go away ?
>
> Sven
>

One approach is to exploit finalization/termination in Lisp.  OpenMCL
has some support for this, though it hasn't been used much, may be
broken, and may or may not scale well in its current implementation.
(Other than that, it's just fine ...)  The code (in
"ccl:library;macptr-termination.lisp") probably won't even compile
in OpenMCL, but the GC functionality it depends on is still there.

For the sake of argument, let's assume that we have a working
mechanism to "finalize" a MACPTR (to be told by the GC that it's
about to be GCed).

When we first introduce a MACPTR to a reference-counted object
(NSObject, CFObject), we retain it (increment its reference count)
and register it for termination/finalization.  As long as Lisp code
can refer to that MACPTR, its reference count will be non-zero and it
won't get freed out from under us.

When Lisp is unable to refer to that MACPTR (as proven by the GC),
the finalization function is called; it releases (decrements the reference
count of) the underlying NSObject/CFObject.  That might or might not
free the underlying object; that's up to the foreign memory-management
code, and lisp has no reason to care either way.

A lot of ObjC objects (especially those that participate in event-handling
functions) are tracked in autorelease pools; the scheme I'm suggesting
might be better suited to dealing with more persistent references.  It
seems right to say "making something accessible to lisp" is about the
same as "giving it indefinite extent", and playing with reference counts
at the points where lisp gains/loses accessibility seems to accomplish
that.


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel