"Hoehle, Joerg-Cyril" Joerg-Cyril.Hoehle@t-systems.com writes:
I'm curious to know how precisely SBCL handles the details.
As far as CLISP is concerned, the second example works (if converted to CLISP FFI syntax), but will leak malloc()'ed memory if it's never deallocated.
From memory: each callback gets allocated separately, and will never
be reclaimed (currently). Each alien-lambda closure gets its own callback.
That is, if your application does not provide for a means to receive the callback address from the alien world, so that the Lisp side can free it, then your application leaks memory.
Right.
This tells us how a lambda callback ought to be designed:
- can create one,
- be able to keep its handle on the Lisp side,
- to be able to destroy it
- via garbage collection
- and/or via stack semantics
- from the C side(?)
CLISP's FFI does not directly fir the bill. You need a little wrapper code. I haven't looked at how CFFI fits these requirements.
I'm not sure I agree. I think the best we can do for callbacks (anonymous or not) is invalidate them: switch the C->Lisp tramp to point to an error-signalling Lisp function, after which the original callback trampoline can be freed (but then we need to lock the trampoline in order not to yank it from beneath another thread -- or do something really clever).
That way any C-function that still happens to have the address we gave it will "act reasonably", instead of landing at a random location -- possibly a new and totally different callback.
I would not like callbacks to ever be released by default, nor from the C-side.
Second, you say "expensive". What do you mean? o The allocation of memory for the callback structure?
The allocation and contruction of the callback trampoline. There are a couple of shortcuts that could be taken to make it significantly more efficient, but they have not been implemented yet.
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."