Martin Simmons wonders:

Jorg> In CLISP, every closure can be turned into a callback, and this is Jorg> valuable since it allows to retrieve context information out of the Jorg> closure. Is cffi's limitation caused by some implementations?

What are the garbage collection semantics of these closures? Presumably the GC can't move them, but when can they be collected?

CLISP can not know by itself when callbacks will cease to be invoked by foreign code. Thus they are created with indefinite extent.

The programmer can have CLISP deallocate a callback by calling FOREIGN-FREE on the FOREIGN-FUNCTION object. This will cause the little callback struct to be free'd(), CLISP's callback tables to be cleaned up (where it holds the mapping from address to Lisp function object associated with it) and thus the Lisp function becomes eligible for GC as well.

In practice this means that the CLISP internal callback table get larger and larger. While CLISP documents the effect of FOREIGN-FREE on FOREIGN-FUNCTION callbacks, I guess nobody but the testsuite uses it.

Note that unlike some other implementations, CLISP stores a Lisp function inside the callback, i.e. its (fdefinition 'foo). It does not store the symbol FOO. Therefore, redefinition of FOO will still invoke the old code.

BTW, one of my diffs to cffi (yet to be sent) explains why cffi:foreign-free cannot be used to free (cffi:callback 'foo).

Regards, Jorg Hohle