[Openmcl-devel] Allocate heap and call C question
Andrew P. Lentvorski, Jr.
bsder at mail.allcaps.org
Tue Jul 6 21:44:34 EDT 2004
On Jul 6, 2004, at 6:15 PM, Dan Knapp wrote:
> I don't have a lot to say on this question, but...
> If the language were to be extended, a more Lisp-like way would be
> to offer a
> special form which allocates an object outside the Lisp heap... but
> with a
> lifetime determined lexically, ie, lasting only until the body of the
> form finishes
> executing. Behind the scenes, the deallocation would be done by having
> unwind-protect call the appropriate function.
> I don't have an opinion yet on whether that would be a good thing;
> but it
> would certainly be better than using explicit deallocation. You could
> implement it yourself, Andrew, fairly easily.
For small allocations, this kind of lexical scoping can be done on the
stack using rlet and rletZ (or, at a lower level, using %stack-block).
For large allocations on the heap, you probably don't want to do an
allocate, copy, send to C, copy on return, and deallocate as an
automatic operation based upon lexical lifetime. The allocated object
is likely to persist across C calls, callbacks, etc. Even some small
allocations want to persist (ie. pointers to GUI elements don't want to
be cleaned up).
Basically, the useful analog would be for small allocations on the heap
vs. small allocations on the stack. Personally, I don't like the idea
of giving too much access to the stack, but that is personal religion
and paranoia speaking rather than solid experience. However, the small
stack allocations have been said to be much faster. *shrug*
That having been said, I will personally probably default to the heap.
However, I will try to reserve full judgment until I have some
experience with these mechanisms in real use. Once I can actually put
together a basic Gtk application, I'll probably have a much better
%stack-block, %vstack-block, with-cstr, rlet, rletZ
I'm leaning toward not, but onl
> -- Dan Knapp
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel