[Sbcl-devel] alien-callbackablethings again

[Nikodemus S. <nik...@ra...>]

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:

Names

   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.

Primitives

   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
   on top.

   class SB-ALIEN:ALIEN-CALLBACK

     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
     ALIEN-CALLBACK.

   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?

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."