"Hoehle, Joerg-Cyril" <[EMAIL PROTECTED]> 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."
_______________________________________________
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
