I've finally gotten around to looking at and thinking about the callbacks
patch, and I think I know a halfway sane way to organize the interface and
am beginning to have some clue of how to integrate it to SBCL:
I'm opting to call these ALIEN-CALLBACKS after all, as that is
what they are used for. Also, while it would be possible to teach
FUNCALL / ALIEN-FUNCALL about these, I'm thinking that it may be
a bit too magical.
I think the following is a sufficient primitive interface (not for the
implementation, but for user-level functionality):
DEFINE-ALIEN-CALLBACK, ALIEN-LAMBDA, and WITH-CALLBACKS are just sugar
Instances of this class are representations of function
designators passable to alien routines as if they were pointers to
alien functions of a given type.
function SB-ALIEN:ALIEN-CALLBACK-FUNCTION alien-callback
Returns the function designator corresponding to the ALIEN-CALLBACK.
function SB-ALIEN:ALIEN-CALLBACK-FTYPE alien-callback
Returns the alien function type specifier associated with the
function SB-ALIEN:ALIEN-CALLBACK alien-ftype function-designator
Returns the alien-callback instance corresponding to the
ALIEN-FTYPE and FUNCTION-DESIGNATOR. A valid alien-callback
is not subject to garbage collection and prevents the
function-designator from being garbage-collected.
If the function designator is a function name calls through the
callback will pick up definition active at the time of the call;
otherwise the same function will be always called.
[ NB: I'm thinking that we should return a unique callback
for each unique pair (under EQUAL) of ALIEN-FTYPE and
FUNCTION-DESIGNATOR, as it eg. makes perfect sense for #'+ to
be callable with both sb-alien:ints and sb-alien:longs.
I'm not so sure how to exactly specify this, though, nor am
I sure about how to detect mismatches between what we know
about the lisp function's type and what ALIEN-FTYPE claims. ]
function SB-ALIEN:INVALIDATE-ALIEN-CALLBACK alien-callback
Invalidates the ALIEN-CALLBACK, making it and the designated
function subject to garbage collection (provided no further refences
to it exist in lisp).
A call to an invalidated alien-callback from foreign code results
in INVALID-ALIEN-CALLBACK-ERROR being signalled.
I'll need to do some more thinking and hacking before saying anything
real about the implementation / integration details, but for now I just
note that the patch also contains and needs support for static vectors,
which I think would be a nice addition to the alien interface in general.
Indirecting the callbacks thru linkage-table as suggested seems viable,
not entrirely straightforward: we still either need the static vectors
as linkage table needs a static address to jump to, or we need to rewrite
the linkage table after each GC (or teach GC to update the table as it
moves callback trampolines). ...so I'm not sure what we would gain going
thru the table in the C -> Lisp direction: we can already trivially
invalidate existing callbacks by replacing the entry in the callback
table with a function what signals an error.
Toughts and comments, please! Anyone else working on this currently?
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."