tech.v3.datatype.ffi.graalvm
Graalvm-specific namespace that implements the dtype-next ffi system and allows users to build stand-alone shared libraries that other languages can use to call Clojure code via a binary C interface.
define-library
(define-library fn-defs symbols {:keys [classname instantiate?], :as options})Define a graal-native set functions bound to a particular native library. See the documentation for tech.v3.datatype.ffi/define-library.
expose-clojure-functions
(expose-clojure-functions fn-defs classname options)Expose a set of clojure functions as graal library entry points. In this case,
the keys of fn-defs are the full namespaced symbols that point to the
fns you want to define. These will be defined to a class named 'classname' and the
resuling class file will be output to *compile-path*.
One caveat - strings are passed as tech.v3.datatype.ffi.Pointer classes and you will have to use tech.v3.datatype.ffi/c->string in order to process them.
Any persistent state must be referenced also from your main class in your jarfile so it will have to reference systems used in your libfile. 'def', 'defonce' variables will show up as uninitialized exceptions at runtime when objects call into your library if they are not referenced in some manner from you jar's main function. This can be achieved via several ways, one of which is to have your exposed namespace referenced from your main namespace or to have your library export file share a common namespace with your main namespace.
- avclj symbol export example.
- calling exposed functions from c++ - note they take an extra parameter, the 'thread isolate'.
- calling libsci from rust, c++, python.
Once you have exposed a set of clojure functions you can then make those functions actual C pointers via the CEntryPointLiteral class. Please see issue 28 for an excellent walkthrough of how to do this. Please note the exposed function will have an extra parameter, the thread isolate, that your C system will have to take care of.