James Bielman wrote: >work with callback pointers in a manner that should be safe >when saving/reloading images.
>I've made some progress updating the callback interface
James, I'm sorry I've ran out of time and could not try out all your recent
additions.
>Jörg, in the CLISP implementation, I'm a little concerned about using
>FFI::EXEC-ON-STACK to convert the functions to callbacks, but I
Indeed, while I don't object using some ffi::... functions which look like they
could have been exported if the FFI had embodied a layered approach,
EXEC-ON-STACK is not among these. IMHO, EXEC-ON-STACK really is the
lowest-level system-internal helper function, depending on other internals and
revealing internal structure not meant for the outside.
>couldn't find another way to get the effect of FFI:WITH-C-VAR at
>runtime, given a parsed type.
Indeed, "given a parsed type" is the problem here.
Think in terms of conversions. You need a foreign place where to store a Lisp
function: this causes generation of a callback, then you need to read it back
to obtain the #<foreign-function> object.
Therefore, a combination of (with-c-var (x 'c-pointer)), SETF CAST and
MEMORY-AS should do the trick (just thinking aloud).
The attached patch includes an answer involving only exported forms.
+ (ffi:with-foreign-object (ptr 'ffi:c-pointer)
+ ;; Create callback by converting Lisp function to foreign
+ (setf (ffi:memory-as ptr parsed-type) function)
+ ;; then construct #<FOREIGN-FUNCTION> object from pointer
+ ;;(ffi:memory-as ptr parsed-type)
+ ;; actually, cffi only keeps the pointer:
+ (ffi:foreign-value ptr)))))
Note that your current code does not free replaced callbacks as the previous
one did. You may want to put that back.
Regard,
Jörg Höhle.
Joerg7.patch
Description: Binary data
_______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
